andygrove commented on PR #27304: URL: https://github.com/apache/datafusion/pull/27304#issuecomment-6800685531
## Logical planning benchmarks (`sql_planner`) I ran the `sql_planner` Criterion benchmarks against the merge base, comparing `9e0a08fd8` (base) with `2aaae27e6` (this PR). Logical planning, which covers parsing plus SQL-to-logical-plan, is faster on all 26 `logical_*` benchmarks. The gains range from 2% to 29%, and they are largest on big or wide SQL. | Benchmark | Base | PR | Change | Speedup | |---|---:|---:|---:|---:| | `logical_wide_filter_200_predicates` | 537.2 µs | 382.8 µs | -28.7% | 1.40x | | `logical_plan_struct_join_agg_sort` | 65.6 µs | 47.8 µs | -27.1% | 1.37x | | `logical_wide_filter_50_predicates` | 172.2 µs | 130.9 µs | -24.0% | 1.32x | | `logical_wide_case_50_exprs` | 678.7 µs | 518.3 µs | -23.6% | 1.31x | | `logical_plan_tpch_all` | 2.31 ms | 1.78 ms | -22.8% | 1.30x | | `logical_join_4_with_agg_and_filter` | 104.8 µs | 82.0 µs | -21.8% | 1.28x | | `logical_join_chain_4` | 43.9 µs | 35.0 µs | -20.2% | 1.25x | | `logical_nested_cte_4_levels` | 109.0 µs | 91.3 µs | -16.2% | 1.19x | | `logical_join_8_with_agg_sort_limit` | 195.7 µs | 167.1 µs | -14.6% | 1.17x | | `logical_plan_tpcds_all` | 34.83 ms | 30.04 ms | -13.8% | 1.16x | | `logical_distinct_many_columns` | 161.5 µs | 139.9 µs | -13.4% | 1.15x | | `logical_wide_aggregate_100_exprs` | 849.8 µs | 750.1 µs | -11.7% | 1.13x | | `logical_join_chain_8` | 125.8 µs | 112.1 µs | -10.9% | 1.12x | | `logical_wide_aggregate_1000_exprs` | 14.43 ms | 13.01 ms | -9.9% | 1.11x | | `logical_correlated_subquery_exists` | 116.5 µs | 108.4 µs | -6.9% | 1.07x | | `logical_union_4_branches` | 206.2 µs | 192.3 µs | -6.7% | 1.07x | | `logical_union_8_branches` | 410.4 µs | 383.6 µs | -6.5% | 1.07x | | `logical_scalar_subquery` | 117.8 µs | 110.5 µs | -6.2% | 1.07x | | `logical_correlated_subquery_in` | 116.5 µs | 109.4 µs | -6.1% | 1.06x | | `logical_join_chain_16` | 429.2 µs | 405.1 µs | -5.6% | 1.06x | | `logical_aggregate_with_join` | 232.8 µs | 219.8 µs | -5.6% | 1.06x | | `logical_multiple_subqueries` | 225.7 µs | 214.7 µs | -4.9% | 1.05x | | `logical_trivial_join_low_numbered_columns` | 148.4 µs | 141.7 µs | -4.5% | 1.05x | | `logical_trivial_join_high_numbered_columns` | 147.0 µs | 142.6 µs | -3.0% | 1.03x | | `logical_select_one_from_700` | 162.1 µs | 158.9 µs | -2.0% | 1.02x | | `logical_select_all_from_1000` | 1.42 ms | 1.40 ms | -1.8% | 1.02x | The `optimizer_*` benchmarks in the same suite start from plans that are already built, so they never call the parser. All 12 of them stayed within ±1.3%, which suggests the gains above come from the parser and not from machine variance between the two runs. <details> <summary>How I ran this</summary> - Machine: Apple M3 Ultra, 28 cores, 96 GB - Command: `cargo bench -p datafusion --bench sql_planner`, run on base with `--save-baseline base`, then on the PR with `--baseline base` - Times are Criterion mean estimates - The `sql_planner.rs` bench source is identical in both trees </details> -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
