Add benchmark for planning sorted unions #14157
Conversation
| @@ -289,6 +362,17 @@ fn criterion_benchmark(c: &mut Criterion) { | |||
| }); | |||
| }); | |||
|
|
|||
| // -- Sorted Queries -- | |||
| register_union_order_table(&ctx, 100, 1000); | |||
There was a problem hiding this comment.
The table has 100 columns
| /// UNION ALL | ||
| /// select null as c1, c2, ... null as cn from t ORDER BY c2 | ||
| /// ... | ||
| /// select null as c1, null as c2, ... cn from t ORDER BY cn |
There was a problem hiding this comment.
do we really need inner ORDER BY if the query got the outer one? 🤔 Shouldn't be inner sorting ignored?
There was a problem hiding this comment.
I probably get it, the problem is with the planning of such query not the execution
There was a problem hiding this comment.
I probably get it, the problem is with the planning of such query not the execution
Yes, exactly
do we really need inner
ORDER BYif the query got the outer one? 🤔 Shouldn't be inner sorting ignored?
Yes, indeed. I think the way it is ignored is that the sort equivalence code determines that the inner sorts aren't needed (or in this case they are all equivalent, so the top order by can a merge rather than sort)
The sort equivalence code (OrderEquivalenceProperties in particular) is what is consuming all this time
Which issue does this PR close?
UNIONandORDER BYqueries #13748Rationale for this change
#13748 is a planning speed problem, so as I increase the performance I want a benchmark that shows the improvements
What changes are included in this PR?
Add bechmark to the
sql_plannersuiteAre these changes tested?
Clippy / compilation is tested via CI
Are there any user-facing changes?
A new benchmark
Are there any user-facing changes?
Check out the flamegraph:
Whole flamegraph:
