Optimize TopK before computed projections#22606
Conversation
|
run benchmarks |
|
🤖 Benchmark running (GKE) | trigger CPU Details (lscpu)Comparing codex/topk-before-projection (46573ef) to 0da8961 (merge-base) diff using: clickbench_partitioned File an issue against this benchmark runner |
|
🤖 Benchmark running (GKE) | trigger CPU Details (lscpu)Comparing codex/topk-before-projection (46573ef) to 0da8961 (merge-base) diff using: tpcds File an issue against this benchmark runner |
|
🤖 Benchmark running (GKE) | trigger CPU Details (lscpu)Comparing codex/topk-before-projection (46573ef) to 0da8961 (merge-base) diff using: tpch File an issue against this benchmark runner |
|
🤖 Benchmark completed (GKE) | trigger Instance: CPU Details (lscpu)Details
Resource Usagetpch — base (merge-base)
tpch — branch
File an issue against this benchmark runner |
|
🤖 Benchmark completed (GKE) | trigger Instance: CPU Details (lscpu)Details
Resource Usagetpcds — base (merge-base)
tpcds — branch
File an issue against this benchmark runner |
|
🤖 Benchmark completed (GKE) | trigger Instance: CPU Details (lscpu)Details
Resource Usageclickbench_partitioned — base (merge-base)
clickbench_partitioned — branch
File an issue against this benchmark runner |
Which issue does this PR close?
Rationale for this change
TopKcan currently run after aProjectionExeceven when the sort key is just a projected input column. If the projection computes values not needed for ordering, such asSELECT 1 ... ORDER BY c LIMIT 10, those expressions are materialized for all input rows instead of only the rows retained byTopK.What changes are included in this PR?
TopKbelow computed projections when all sort keys map through the projection to plain input columns.Are these changes tested?
Are there any user-facing changes?
No API changes. Physical plans for some
TopKqueries with computed projections can change; query results are unchanged.