SQL heavy-hitter gate misses count-ranked topk when COUNT is aliased

[milindsrivastava1997]

Summary

Two SQL queries with identical semantics produce different L3 IR depending on whether the COUNT(*) is aliased in the ORDER BY. The heavy-hitter gate only fires when ORDER BY COUNT(*) DESC appears literally; referencing the count via an alias defeats it.

Reproduction

-- S1: alias — falls through to Sort+Limit (WRONG: should be heavy-hitter)
SELECT service, COUNT(*) AS cnt
FROM metrics
GROUP BY service
ORDER BY cnt DESC LIMIT 5

L3 output:

Limit { Sort { Project { Aggregate(Count) } } }

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

L3 output:

Aggregate(TopK { k:5 })

Expected

Both queries should produce the same L3 IR — the heavy-hitter Aggregate(TopK) — since they are semantically identical.

Reproduce via example

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

Labels: S1, S2