Skip to content

Commit 0244096

Browse files
Updated docs
1 parent 0e5655c commit 0244096

1 file changed

Lines changed: 8 additions & 6 deletions

File tree

.docs/CAPABILITY_MATCHING_DESIGN.md

Lines changed: 8 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -2,13 +2,13 @@
22

33
## Problem Statement
44

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.
78

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.
1212

1313
The goal: let the engine understand what a query *needs* and find an existing aggregation that can
1414
*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
3030
The `QueryConfig` table is just indirection that requires manual pre-population. The fix is to
3131
skip it and match against `AggregationConfig` directly when no pre-configured entry exists.
3232

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
34+
3335
---
3436

3537
## Design Questions and Answers

0 commit comments

Comments
 (0)