Skip to content

L3 IR structural inconsistency: SQL and PromQL heavy-hitter topk produce different tree shapes #25

Description

@milindsrivastava1997

Summary

When the heavy-hitter path fires, SQL and PromQL produce Aggregate(TopK) nodes with different child structures. In SQL the Count is implicit (TopK wraps the raw scan); in PromQL the Count is an explicit child aggregate. An L4 rule matching on AggIntent::TopK sees structurally different subtrees depending on which language the query came from.

Reproduction

-- S2 — SQL heavy-hitter (inline COUNT)
SELECT service, COUNT(*)
FROM metrics GROUP BY service
ORDER BY COUNT(*) DESC LIMIT 5

L3 output:

Aggregate { by: [1], aggs: [TopK { k:5 }], child: Scan }
# P1 — PromQL heavy-hitter
topk(5, count_over_time(http_requests_total[5m]))

# P10 — PromQL heavy-hitter with by
topk by (service) (5, count_over_time(http_requests_total[5m]))

L3 output for P1:

Aggregate { by: [], aggs: [TopK { k:5 }],
    child: Aggregate { aggs: [Count],
        child: TimeRange { child: Scan }
    }
}

Difference

SQL S2 PromQL P1/P10
TopK child Scan (raw rows) Aggregate(Count) { TimeRange { Scan } }
Count Implicit within TopK Explicit child node

Notes

The difference may be partially intentional (SQL counts table rows; PromQL counts time-series samples over a window). But L4 rules need to be aware that AggIntent::TopK's child has a different shape depending on origin language. Worth deciding whether to normalize this.

Reproduce via example

cargo run -p asap-control-lower --example topk_ir

Labels: S2, P1, P10

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions