You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .docs/CAPABILITY_MATCHING_DESIGN.md
+8-6Lines changed: 8 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,13 +2,13 @@
2
2
3
3
## Problem Statement
4
4
5
-
The query engine previously routed every incoming query to a sketch aggregation by matching the
6
-
query string against a pre-configured `query_configs` table in `InferenceConfig`. This meant:
5
+
Currntly, when query engine gets a query, it does an exact string match of that query against the inference config to find what aggregation ID to use. This results in 2 problems:
6
+
1. It also requires the inference config to exactly specify each and every query that can be supported.
7
+
2. This does NOT handle ad-hoc queries for which we may still have a sketch that is computed.
7
8
8
-
- Every distinct query string needed its own config entry, even when the same sketch could answer
9
-
multiple queries (e.g. `quantile(0.5, metric[5m])` and `quantile(0.9, metric[5m])` both need a
10
-
KLL sketch, but each required a separate config row).
11
-
- The system could not answer any query it had not been explicitly pre-configured for.
9
+
For instance, even when the same sketch can answer both `quantile(0.5, metric[5m])` and `quantile(0.9, metric[5m])`, we need 2 entries in inference config`.
10
+
11
+
Moreover, if we now get `quantile(0.6, metric[5m])` or `quantile(0.5, metric[10m])`, those queries get punted even if we can support them.
12
12
13
13
The goal: let the engine understand what a query *needs* and find an existing aggregation that can
14
14
*provide* it, without requiring a one-to-one mapping in config.
@@ -30,6 +30,8 @@ The key insight: **all capability information lives in `AggregationConfig` insid
30
30
The `QueryConfig` table is just indirection that requires manual pre-population. The fix is to
31
31
skip it and match against `AggregationConfig` directly when no pre-configured entry exists.
32
32
33
+
So the logic now is (a) define what the query needs (QueryRequirements), (b) match QueryRequirements against all the available aggregation_ids to see if there is a match. There is no explicit CapabilityProvidedBySketch data structure
0 commit comments