docs: re-doing documentation - #180
Conversation
# Conflicts: # README.md # docs/l2-intent-algebra.md # docs/l3-intent-algebra.md # docs/l3-summary-bound-ir.md # docs/l4-physical-plan.md # docs/l4-summary-bound-ir.md # docs/l5-physical-plan.md # old_docs/docs/l2-logical-plan.md # old_docs/docs/l3-intent-algebra.md # old_docs/docs/l4-summary-bound-ir.md # old_docs/docs/l5-physical-plan.md
milindsrivastava1997
changed the title
|
|
||
| The pre-ASAP IR is defined using the `QueryExpr` enum. We discuss some of important enum types below. | ||
|
|
||
| ## Node index |
There was a problem hiding this comment.
https://github.com/ProjectASAP/ASAPController/blob/main/docs/pre-asap-ir.md#node-index node index now is mixing SQL specific node and PromQL specific nodes, e..g, Scan/filter, vs infojoin
| meaningful summary implementation. | ||
|
|
||
| **Fields** (real implementation — differs from the sketch above, see #185): | ||
| - `reduction` — whether this is a genuine cross-entity reduction (`Reduce(GroupKeys)`) or a per-entity pass-through with no grouping concept at all (`PerEntity`). |
There was a problem hiding this comment.
TODO: need to check this with examples, but I remember this was introduced due to a real example need.
| - `aggs` — the aggregate intents to compute (`Sum`, `Rate`, `HistogramQuantile`, ...). | ||
| - `output_names` — output column name per entry in `aggs`; overrides the synthetic default when non-empty. | ||
| - `having` — an optional post-aggregation filter predicate (SQL `HAVING`). | ||
| - `child` — the input being aggregated. |
There was a problem hiding this comment.
These seem too implementation level.
|
|
||
| ### Subquery | ||
|
|
||
| PromQL sub-query syntax `<expr>[range:resolution]` — a logical pass-through that lets a |
There was a problem hiding this comment.
<instant_query> [ : [ ] ] [ offset ]
as promql sub-query syntax
| SELECT * FROM (SELECT srcip, COUNT(*) AS cnt FROM packets GROUP BY srcip) t WHERE cnt > 10 | ||
| ``` | ||
|
|
||
| **Fields:** |
There was a problem hiding this comment.
How did these "Fields" come up? They look implementation level and not related to the node definitions themselves.
| - `left` — the left branch. | ||
| - `right` — the right branch. | ||
|
|
||
| ### Merge |
There was a problem hiding this comment.
TODO: need to note Merge node is not SQL nor PromQL, it is a node introduced by ASAP for representing multi-branch query result supported by one query expression, or one intermediate state?
|
|
||
| ### Scalar | ||
|
|
||
| A scalar constant leaf — a PromQL number literal, or a folded constant scalar expression. |
There was a problem hiding this comment.
This looks like a binary operation node as SQL, why it is PromQL specific?
| time() | ||
| ``` | ||
|
|
||
| ### VectorFromScalar |
There was a problem hiding this comment.
Not sure if these are needed for the common IR layer. they will appear in promql parser output I agree.
Addresses PR #180 review comment: the flat node index mixed SQL-only and PromQL-only nodes together (e.g. Scan/Filter next to InfoJoin) with no indication of scope. Group it under the same section headers used in the body (aggregation/time/relational/PromQL/SQL) so scope is visible at a glance.
2 participants
No description provided.