You are viewing a plain text version of this content. The canonical link for it is here.
Posted to github@datafusion.apache.org by "kumarUjjawal (via GitHub)" <gi...@apache.org> on 2026/06/11 08:23:34 UTC
[PR] Fix optimize_projections failure with struct-field join keys [datafusion]
kumarUjjawal opened a new pull request, #22903:
URL: https://github.com/apache/datafusion/pull/22903
## Which issue does this PR close?
<!--
We generally require a GitHub issue to be filed for all bug fixes and enhancements and this helps us generate change logs for our releases. You can link an issue to this PR using the GitHub syntax. For example `Closes #123` indicates that this PR will close issue #123.
-->
- Closes #22895.
## Rationale for this change
Join-key extraction can add helper projections and change a child plan's output schema. Some parent nodes cache their schema, so after the child rewrite they can still expose stale fields. Later projection pruning then uses the stale schema and fails with missing-column errors.
<!--
Why are you proposing this change? If this is already explained clearly in the issue then this section is not needed.
Explaining clearly why changes are proposed helps reviewers understand your changes and offer better suggestions for fixes.
-->
## What changes are included in this PR?
- Refresh a parent schema only when a rewritten child reports an actual schema change.
- Re-check whether the plan has subqueries before each rule, so plans that are decorrelated by earlier rules can use the in-place path in the same optimizer pass.
- Add regression coverage for the reported struct-field join-key failures.
- Add a regression case for union output labels while union-to-filter rewriting is enabled.
- Add a focused optimizer unit test for parent schema refresh after child schema changes.
- Update one existing optimized-plan expectation. The new plan removes a redundant dedup step; the surrounding semi joins already preserve distinctness.
<!--
There is no need to duplicate the description in the issue here but it is sometimes worth providing a summary of the individual changes in this PR.
-->
## Are these changes tested?
Yes
<!--
We typically require tests for all PRs in order to:
1. Prevent the code from being accidentally broken by subsequent changes
2. Serve as another way to document the expected behavior of the code
If tests are not included in your PR, please explain why (for example, are they covered by existing tests)?
-->
## Are there any user-facing changes?
No
<!--
If there are user-facing changes then we may require documentation to be updated before approving the PR.
-->
<!--
If there are any breaking changes to public APIs, please add the `api change` label.
-->
--
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: github-unsubscribe@datafusion.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For additional commands, e-mail: github-help@datafusion.apache.org
Re: [PR] fix: optimize_projections failure with struct-field join keys [datafusion]
Posted by "kumarUjjawal (via GitHub)" <gi...@apache.org>.
kumarUjjawal commented on code in PR #22903:
URL: https://github.com/apache/datafusion/pull/22903#discussion_r3432960743
##########
datafusion/optimizer/src/optimizer.rs:
##########
@@ -604,15 +617,14 @@ impl Optimizer {
while i < options.optimizer.max_passes {
log_plan(&format!("Optimizer input (pass {i})"), &new_plan);
- // Check once per pass whether the plan contains subquery
- // expressions. When there are no subqueries, we use the
- // cheaper `rewrite` traversal instead of
- // `rewrite_with_subqueries`, avoiding the per-node
- // map_subqueries call that walks all expression trees
- // via ownership-based transform_down.
- let has_subqueries = plan_has_subqueries(&new_plan);
-
for rule in &self.rules {
+ // Re-check for each rule: early rules can remove subquery
+ // expressions, allowing later rules to use the cheaper in-place
+ // traversal in the same optimizer pass. This is also
+ // correctness-sensitive: the in-place path refreshes parent
+ // schemas after child schemas change.
+ let has_subqueries = plan_has_subqueries(&new_plan);
Review Comment:
Thank you! I should have caught this.
--
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: github-unsubscribe@datafusion.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For additional commands, e-mail: github-help@datafusion.apache.org
Re: [PR] fix: optimize_projections failure with struct-field join keys [datafusion]
Posted by "adriangbot (via GitHub)" <gi...@apache.org>.
adriangbot commented on PR #22903:
URL: https://github.com/apache/datafusion/pull/22903#issuecomment-4808736670
🤖 Benchmark running (GKE) | [trigger](https://github.com/apache/datafusion/pull/22903#issuecomment-4808729453)
**Instance:** `c4a-highmem-16` (12 vCPU / 65 GiB) | `Linux bench-c4808729453-706-pk4k5 6.12.85+ #1 SMP Mon May 11 08:17:35 UTC 2026 aarch64 GNU/Linux`
<details><summary>CPU Details (lscpu)</summary>
```
Architecture: aarch64
CPU op-mode(s): 64-bit
Byte Order: Little Endian
CPU(s): 16
On-line CPU(s) list: 0-15
Vendor ID: ARM
Model name: Neoverse-V2
Model: 1
Thread(s) per core: 1
Core(s) per cluster: 16
Socket(s): -
Cluster(s): 1
Stepping: r0p1
BogoMIPS: 2000.00
Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 sm3 sm4 asimddp sha512 sve asimdfhm dit uscat ilrcpc flagm sb paca pacg dcpodp sve2 sveaes svepmull svebitperm svesha3 svesm4 flagm2 frint svei8mm svebf16 i8mm bf16 dgh rng bti
L1d cache: 1 MiB (16 instances)
L1i cache: 1 MiB (16 instances)
L2 cache: 32 MiB (16 instances)
L3 cache: 80 MiB (1 instance)
NUMA node(s): 1
NUMA node0 CPU(s): 0-15
Vulnerability Gather data sampling: Not affected
Vulnerability Indirect target selection: Not affected
Vulnerability Itlb multihit: Not affected
Vulnerability L1tf: Not affected
Vulnerability Mds: Not affected
Vulnerability Meltdown: Not affected
Vulnerability Mmio stale data: Not affected
Vulnerability Reg file data sampling: Not affected
Vulnerability Retbleed: Not affected
Vulnerability Spec rstack overflow: Not affected
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
Vulnerability Spectre v1: Mitigation; __user pointer sanitization
Vulnerability Spectre v2: Mitigation; CSV2, BHB
Vulnerability Srbds: Not affected
Vulnerability Tsa: Not affected
Vulnerability Tsx async abort: Not affected
Vulnerability Vmscape: Not affected
```
</details>
Comparing fix/no-field-name-join (144d0e95adfc90bc80ae14dc1c10b7da17282d71) to d77a02d (merge-base) [diff](https://github.com/apache/datafusion/compare/d77a02d662b27852cc247153d9edcad5a92905d4..144d0e95adfc90bc80ae14dc1c10b7da17282d71) using: sql_planner
Results will be posted here when complete
---
[File an issue](https://github.com/adriangb/datafusion-benchmarking/issues) against this benchmark runner
--
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: github-unsubscribe@datafusion.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For additional commands, e-mail: github-help@datafusion.apache.org
Re: [PR] fix: optimize_projections failure with struct-field join keys [datafusion]
Posted by "adriangb (via GitHub)" <gi...@apache.org>.
adriangb merged PR #22903:
URL: https://github.com/apache/datafusion/pull/22903
--
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: github-unsubscribe@datafusion.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For additional commands, e-mail: github-help@datafusion.apache.org
Re: [PR] fix: optimize_projections failure with struct-field join keys [datafusion]
Posted by "adriangb (via GitHub)" <gi...@apache.org>.
adriangb commented on PR #22903:
URL: https://github.com/apache/datafusion/pull/22903#issuecomment-4808729453
run benchmark sql_planner
--
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: github-unsubscribe@datafusion.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For additional commands, e-mail: github-help@datafusion.apache.org
Re: [PR] fix: optimize_projections failure with struct-field join keys [datafusion]
Posted by "adriangbot (via GitHub)" <gi...@apache.org>.
adriangbot commented on PR #22903:
URL: https://github.com/apache/datafusion/pull/22903#issuecomment-4809366475
🤖 Benchmark completed (GKE) | [trigger](https://github.com/apache/datafusion/pull/22903#issuecomment-4808729453)
**Instance:** `c4a-highmem-16` (12 vCPU / 65 GiB)
<details><summary>CPU Details (lscpu)</summary>
```
Architecture: aarch64
CPU op-mode(s): 64-bit
Byte Order: Little Endian
CPU(s): 16
On-line CPU(s) list: 0-15
Vendor ID: ARM
Model name: Neoverse-V2
Model: 1
Thread(s) per core: 1
Core(s) per cluster: 16
Socket(s): -
Cluster(s): 1
Stepping: r0p1
BogoMIPS: 2000.00
Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 sm3 sm4 asimddp sha512 sve asimdfhm dit uscat ilrcpc flagm sb paca pacg dcpodp sve2 sveaes svepmull svebitperm svesha3 svesm4 flagm2 frint svei8mm svebf16 i8mm bf16 dgh rng bti
L1d cache: 1 MiB (16 instances)
L1i cache: 1 MiB (16 instances)
L2 cache: 32 MiB (16 instances)
L3 cache: 80 MiB (1 instance)
NUMA node(s): 1
NUMA node0 CPU(s): 0-15
Vulnerability Gather data sampling: Not affected
Vulnerability Indirect target selection: Not affected
Vulnerability Itlb multihit: Not affected
Vulnerability L1tf: Not affected
Vulnerability Mds: Not affected
Vulnerability Meltdown: Not affected
Vulnerability Mmio stale data: Not affected
Vulnerability Reg file data sampling: Not affected
Vulnerability Retbleed: Not affected
Vulnerability Spec rstack overflow: Not affected
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
Vulnerability Spectre v1: Mitigation; __user pointer sanitization
Vulnerability Spectre v2: Mitigation; CSV2, BHB
Vulnerability Srbds: Not affected
Vulnerability Tsa: Not affected
Vulnerability Tsx async abort: Not affected
Vulnerability Vmscape: Not affected
```
</details>
<details><summary>Details</summary>
<p>
```
group HEAD fix_no-field-name-join
----- ---- ----------------------
logical_aggregate_with_join 1.01 459.7±0.73µs ? ?/sec 1.00 454.8±2.11µs ? ?/sec
logical_correlated_subquery_exists 1.02 286.0±0.99µs ? ?/sec 1.00 281.3±1.50µs ? ?/sec
logical_correlated_subquery_in 1.02 287.7±1.52µs ? ?/sec 1.00 283.0±1.02µs ? ?/sec
logical_distinct_many_columns 1.01 576.5±1.45µs ? ?/sec 1.00 572.4±0.74µs ? ?/sec
logical_join_4_with_agg_and_filter 1.00 250.4±0.83µs ? ?/sec 1.00 249.4±1.01µs ? ?/sec
logical_join_8_with_agg_sort_limit 1.00 422.7±1.87µs ? ?/sec 1.00 421.3±1.36µs ? ?/sec
logical_join_chain_16 1.01 684.1±4.10µs ? ?/sec 1.00 676.8±3.53µs ? ?/sec
logical_join_chain_4 1.02 122.1±0.25µs ? ?/sec 1.00 119.6±0.36µs ? ?/sec
logical_join_chain_8 1.02 251.7±1.06µs ? ?/sec 1.00 247.8±0.75µs ? ?/sec
logical_multiple_subqueries 1.01 523.3±3.29µs ? ?/sec 1.00 516.9±7.38µs ? ?/sec
logical_nested_cte_4_levels 1.03 266.2±1.12µs ? ?/sec 1.00 257.5±1.27µs ? ?/sec
logical_plan_struct_join_agg_sort 1.01 177.5±1.71µs ? ?/sec 1.00 176.1±0.69µs ? ?/sec
logical_plan_tpcds_all 1.00 92.4±0.13ms ? ?/sec 1.00 92.3±0.15ms ? ?/sec
logical_plan_tpch_all 1.02 6.5±0.02ms ? ?/sec 1.00 6.4±0.02ms ? ?/sec
logical_scalar_subquery 1.01 308.7±0.92µs ? ?/sec 1.00 305.7±1.17µs ? ?/sec
logical_select_all_from_1000 1.00 105.0±0.30ms ? ?/sec 1.00 104.6±0.29ms ? ?/sec
logical_select_one_from_700 1.01 330.4±1.86µs ? ?/sec 1.00 328.5±1.80µs ? ?/sec
logical_trivial_join_high_numbered_columns 1.00 289.6±1.07µs ? ?/sec 1.00 289.6±1.12µs ? ?/sec
logical_trivial_join_low_numbered_columns 1.01 277.6±1.05µs ? ?/sec 1.00 276.0±1.20µs ? ?/sec
logical_union_4_branches 1.02 428.2±2.55µs ? ?/sec 1.00 421.6±2.23µs ? ?/sec
logical_union_8_branches 1.00 814.9±3.42µs ? ?/sec 1.00 817.9±4.57µs ? ?/sec
logical_wide_aggregate_100_exprs 1.00 4.3±0.01ms ? ?/sec 1.00 4.3±0.02ms ? ?/sec
logical_wide_case_50_exprs 1.01 2.4±0.00ms ? ?/sec 1.00 2.4±0.00ms ? ?/sec
logical_wide_filter_200_predicates 1.00 1306.9±10.30µs ? ?/sec 1.00 1308.3±8.74µs ? ?/sec
logical_wide_filter_50_predicates 1.01 389.7±2.77µs ? ?/sec 1.00 387.2±2.31µs ? ?/sec
optimizer_correlated_exists 1.02 250.6±0.67µs ? ?/sec 1.00 246.5±0.80µs ? ?/sec
optimizer_join_4_with_agg_filter 1.00 427.4±1.66µs ? ?/sec 1.04 445.0±1.00µs ? ?/sec
optimizer_join_chain_4 1.00 169.3±0.46µs ? ?/sec 1.04 176.8±0.64µs ? ?/sec
optimizer_join_chain_8 1.00 541.3±1.93µs ? ?/sec 1.03 558.9±1.24µs ? ?/sec
optimizer_select_all_from_1000 1.00 4.6±0.01ms ? ?/sec 1.00 4.6±0.02ms ? ?/sec
optimizer_select_one_from_700 1.00 263.2±0.68µs ? ?/sec 1.00 263.7±0.51µs ? ?/sec
optimizer_tpcds_all 1.00 286.2±0.44ms ? ?/sec 1.02 291.9±0.23ms ? ?/sec
optimizer_tpch_all 1.00 15.1±0.04ms ? ?/sec 1.01 15.3±0.03ms ? ?/sec
optimizer_wide_aggregate_100 1.00 2.1±0.00ms ? ?/sec 1.00 2.1±0.00ms ? ?/sec
optimizer_wide_filter_200 1.00 3.5±0.01ms ? ?/sec 1.02 3.6±0.01ms ? ?/sec
physical_intersection 1.00 598.1±2.54µs ? ?/sec 1.00 596.8±2.37µs ? ?/sec
physical_join_consider_sort 1.00 1033.8±2.96µs ? ?/sec 1.01 1039.0±2.61µs ? ?/sec
physical_join_distinct 1.01 271.2±2.66µs ? ?/sec 1.00 269.4±1.02µs ? ?/sec
physical_many_self_joins 1.00 7.4±0.01ms ? ?/sec 1.00 7.5±0.01ms ? ?/sec
physical_plan_clickbench_all 1.00 121.2±0.50ms ? ?/sec 1.02 123.4±0.24ms ? ?/sec
physical_plan_clickbench_q1 1.00 1312.1±5.86µs ? ?/sec 1.00 1310.0±7.43µs ? ?/sec
physical_plan_clickbench_q10 1.01 1937.7±7.95µs ? ?/sec 1.00 1919.4±5.63µs ? ?/sec
physical_plan_clickbench_q11 1.00 2.1±0.01ms ? ?/sec 1.02 2.1±0.00ms ? ?/sec
physical_plan_clickbench_q12 1.00 2.1±0.01ms ? ?/sec 1.01 2.2±0.00ms ? ?/sec
physical_plan_clickbench_q13 1.00 1927.9±7.69µs ? ?/sec 1.01 1943.2±4.95µs ? ?/sec
physical_plan_clickbench_q14 1.00 2.1±0.01ms ? ?/sec 1.00 2.1±0.01ms ? ?/sec
physical_plan_clickbench_q15 1.00 1990.9±7.00µs ? ?/sec 1.00 1997.6±6.45µs ? ?/sec
physical_plan_clickbench_q16 1.00 1675.9±5.73µs ? ?/sec 1.00 1676.4±5.34µs ? ?/sec
physical_plan_clickbench_q17 1.00 1721.9±6.04µs ? ?/sec 1.00 1720.8±6.05µs ? ?/sec
physical_plan_clickbench_q18 1.00 1588.2±4.72µs ? ?/sec 1.01 1608.2±5.23µs ? ?/sec
physical_plan_clickbench_q19 1.00 1939.2±5.73µs ? ?/sec 1.00 1930.6±7.95µs ? ?/sec
physical_plan_clickbench_q2 1.00 1702.0±6.01µs ? ?/sec 1.01 1712.8±7.74µs ? ?/sec
physical_plan_clickbench_q20 1.00 1491.5±5.72µs ? ?/sec 1.00 1491.5±5.74µs ? ?/sec
physical_plan_clickbench_q21 1.00 1699.9±5.67µs ? ?/sec 1.00 1704.8±6.21µs ? ?/sec
physical_plan_clickbench_q22 1.00 2.0±0.01ms ? ?/sec 1.01 2.1±0.00ms ? ?/sec
physical_plan_clickbench_q23 1.00 2.2±0.00ms ? ?/sec 1.01 2.2±0.01ms ? ?/sec
physical_plan_clickbench_q24 1.00 6.6±0.01ms ? ?/sec 1.00 6.6±0.01ms ? ?/sec
physical_plan_clickbench_q25 1.00 1838.9±5.86µs ? ?/sec 1.00 1838.5±4.53µs ? ?/sec
physical_plan_clickbench_q26 1.00 1679.0±5.05µs ? ?/sec 1.00 1680.7±5.68µs ? ?/sec
physical_plan_clickbench_q27 1.00 1842.5±11.37µs ? ?/sec 1.01 1859.6±4.56µs ? ?/sec
physical_plan_clickbench_q28 1.00 2.3±0.02ms ? ?/sec 1.01 2.3±0.01ms ? ?/sec
physical_plan_clickbench_q29 1.00 2.4±0.02ms ? ?/sec 1.00 2.4±0.01ms ? ?/sec
physical_plan_clickbench_q3 1.00 1572.3±5.73µs ? ?/sec 1.01 1586.2±5.08µs ? ?/sec
physical_plan_clickbench_q30 1.01 15.1±0.08ms ? ?/sec 1.00 15.0±0.03ms ? ?/sec
physical_plan_clickbench_q31 1.00 2.3±0.01ms ? ?/sec 1.00 2.3±0.01ms ? ?/sec
physical_plan_clickbench_q32 1.00 2.3±0.01ms ? ?/sec 1.00 2.3±0.01ms ? ?/sec
physical_plan_clickbench_q33 1.01 1932.5±5.59µs ? ?/sec 1.00 1911.2±4.79µs ? ?/sec
physical_plan_clickbench_q34 1.01 1699.1±4.81µs ? ?/sec 1.00 1689.4±5.82µs ? ?/sec
physical_plan_clickbench_q35 1.00 1765.6±5.20µs ? ?/sec 1.00 1758.7±5.82µs ? ?/sec
physical_plan_clickbench_q36 1.01 2.1±0.00ms ? ?/sec 1.00 2.1±0.01ms ? ?/sec
physical_plan_clickbench_q37 1.01 2.4±0.02ms ? ?/sec 1.00 2.4±0.01ms ? ?/sec
physical_plan_clickbench_q38 1.00 2.4±0.02ms ? ?/sec 1.00 2.4±0.01ms ? ?/sec
physical_plan_clickbench_q39 1.00 2.5±0.01ms ? ?/sec 1.02 2.5±0.01ms ? ?/sec
physical_plan_clickbench_q4 1.00 1394.1±5.15µs ? ?/sec 1.00 1387.8±4.95µs ? ?/sec
physical_plan_clickbench_q40 1.00 3.2±0.01ms ? ?/sec 1.00 3.2±0.01ms ? ?/sec
physical_plan_clickbench_q41 1.00 2.7±0.01ms ? ?/sec 1.01 2.8±0.01ms ? ?/sec
physical_plan_clickbench_q42 1.00 2.9±0.01ms ? ?/sec 1.01 3.0±0.01ms ? ?/sec
physical_plan_clickbench_q43 1.00 3.0±0.01ms ? ?/sec 1.01 3.1±0.01ms ? ?/sec
physical_plan_clickbench_q44 1.00 1481.2±6.21µs ? ?/sec 1.02 1507.1±5.61µs ? ?/sec
physical_plan_clickbench_q45 1.00 1487.3±5.22µs ? ?/sec 1.02 1513.0±5.25µs ? ?/sec
physical_plan_clickbench_q46 1.00 1766.3±6.53µs ? ?/sec 1.02 1808.3±5.90µs ? ?/sec
physical_plan_clickbench_q47 1.00 2.5±0.01ms ? ?/sec 1.01 2.5±0.01ms ? ?/sec
physical_plan_clickbench_q48 1.00 2.7±0.01ms ? ?/sec 1.02 2.7±0.01ms ? ?/sec
physical_plan_clickbench_q49 1.00 2.7±0.01ms ? ?/sec 1.02 2.8±0.01ms ? ?/sec
physical_plan_clickbench_q5 1.01 1520.9±6.32µs ? ?/sec 1.00 1510.8±4.59µs ? ?/sec
physical_plan_clickbench_q50 1.00 2.6±0.04ms ? ?/sec 1.02 2.6±0.01ms ? ?/sec
physical_plan_clickbench_q51 1.00 1852.0±16.95µs ? ?/sec 1.03 1905.1±5.38µs ? ?/sec
physical_plan_clickbench_q6 1.01 1526.9±7.52µs ? ?/sec 1.00 1517.2±6.25µs ? ?/sec
physical_plan_clickbench_q7 1.00 1356.7±6.34µs ? ?/sec 1.00 1350.6±3.98µs ? ?/sec
physical_plan_clickbench_q8 1.01 1856.8±5.60µs ? ?/sec 1.00 1831.3±4.29µs ? ?/sec
physical_plan_clickbench_q9 1.01 1815.9±5.14µs ? ?/sec 1.00 1800.8±10.22µs ? ?/sec
physical_plan_struct_join_agg_sort 1.00 1260.5±2.56µs ? ?/sec 1.00 1255.7±2.47µs ? ?/sec
physical_plan_tpcds_all 1.00 697.9±0.55ms ? ?/sec 1.00 700.5±1.18ms ? ?/sec
physical_plan_tpch_all 1.00 43.0±0.06ms ? ?/sec 1.00 42.9±0.07ms ? ?/sec
physical_plan_tpch_q1 1.02 1500.6±2.02µs ? ?/sec 1.00 1466.1±2.12µs ? ?/sec
physical_plan_tpch_q10 1.00 2.8±0.00ms ? ?/sec 1.00 2.8±0.00ms ? ?/sec
physical_plan_tpch_q11 1.01 2.1±0.00ms ? ?/sec 1.00 2.0±0.00ms ? ?/sec
physical_plan_tpch_q12 1.01 1221.4±2.11µs ? ?/sec 1.00 1204.6±2.39µs ? ?/sec
physical_plan_tpch_q13 1.00 987.6±2.32µs ? ?/sec 1.01 998.7±6.49µs ? ?/sec
physical_plan_tpch_q14 1.01 1416.9±2.60µs ? ?/sec 1.00 1396.5±11.99µs ? ?/sec
physical_plan_tpch_q16 1.00 1530.6±4.32µs ? ?/sec 1.00 1526.7±2.05µs ? ?/sec
physical_plan_tpch_q17 1.00 1659.9±10.26µs ? ?/sec 1.00 1657.9±3.18µs ? ?/sec
physical_plan_tpch_q18 1.00 1881.1±4.15µs ? ?/sec 1.00 1882.1±3.02µs ? ?/sec
physical_plan_tpch_q19 1.00 1668.9±3.26µs ? ?/sec 1.00 1667.9±3.75µs ? ?/sec
physical_plan_tpch_q2 1.00 3.6±0.00ms ? ?/sec 1.01 3.6±0.00ms ? ?/sec
physical_plan_tpch_q20 1.00 2.2±0.01ms ? ?/sec 1.00 2.2±0.00ms ? ?/sec
physical_plan_tpch_q21 1.00 3.0±0.01ms ? ?/sec 1.00 3.0±0.00ms ? ?/sec
physical_plan_tpch_q22 1.01 1545.0±7.62µs ? ?/sec 1.00 1525.8±3.81µs ? ?/sec
physical_plan_tpch_q3 1.01 1866.6±3.10µs ? ?/sec 1.00 1849.9±3.41µs ? ?/sec
physical_plan_tpch_q4 1.01 1186.7±3.33µs ? ?/sec 1.00 1169.5±2.69µs ? ?/sec
physical_plan_tpch_q5 1.01 2.5±0.00ms ? ?/sec 1.00 2.4±0.00ms ? ?/sec
physical_plan_tpch_q6 1.01 639.5±1.42µs ? ?/sec 1.00 633.4±1.49µs ? ?/sec
physical_plan_tpch_q7 1.00 2.8±0.00ms ? ?/sec 1.00 2.8±0.00ms ? ?/sec
physical_plan_tpch_q8 1.01 3.6±0.00ms ? ?/sec 1.00 3.6±0.00ms ? ?/sec
physical_plan_tpch_q9 1.01 2.4±0.00ms ? ?/sec 1.00 2.4±0.00ms ? ?/sec
physical_select_aggregates_from_200 1.00 15.5±0.02ms ? ?/sec 1.00 15.4±0.03ms ? ?/sec
physical_select_all_from_1000 1.00 114.0±0.31ms ? ?/sec 1.00 113.8±0.27ms ? ?/sec
physical_select_one_from_700 1.00 789.5±3.01µs ? ?/sec 1.00 789.0±2.49µs ? ?/sec
physical_sorted_union_order_by_10_int64 1.00 4.3±0.01ms ? ?/sec 1.00 4.3±0.00ms ? ?/sec
physical_sorted_union_order_by_10_uint64 1.00 8.3±0.01ms ? ?/sec 1.00 8.4±0.01ms ? ?/sec
physical_sorted_union_order_by_50_int64 1.00 107.4±0.31ms ? ?/sec 1.00 107.6±0.29ms ? ?/sec
physical_sorted_union_order_by_50_uint64 1.00 356.0±0.86ms ? ?/sec 1.01 358.7±1.00ms ? ?/sec
physical_theta_join_consider_sort 1.00 1063.1±2.73µs ? ?/sec 1.01 1069.5±3.14µs ? ?/sec
physical_unnest_to_join 1.01 670.6±7.02µs ? ?/sec 1.00 660.8±2.03µs ? ?/sec
physical_window_function_partition_by_12_on_values 1.01 727.1±5.37µs ? ?/sec 1.00 721.6±1.83µs ? ?/sec
physical_window_function_partition_by_30_on_values 1.00 1444.5±5.01µs ? ?/sec 1.01 1452.9±9.54µs ? ?/sec
physical_window_function_partition_by_4_on_values 1.01 436.6±1.54µs ? ?/sec 1.00 433.2±1.44µs ? ?/sec
physical_window_function_partition_by_7_on_values 1.01 542.4±1.77µs ? ?/sec 1.00 535.3±1.65µs ? ?/sec
physical_window_function_partition_by_8_on_values 1.00 582.3±2.61µs ? ?/sec 1.00 581.4±1.68µs ? ?/sec
with_param_values_many_columns 1.00 429.0±1.71µs ? ?/sec 1.01 434.2±1.96µs ? ?/sec
```
</p>
</details>
<details><summary>Resource Usage</summary>
**sql_planner — base (merge-base)**
| Metric | Value |
|--------|-------|
| Wall time | 2465.5s |
| Peak memory | 130.2 MiB |
| Avg memory | 63.6 MiB |
| CPU user | 1877.2s |
| CPU sys | 1.4s |
| Peak spill | 0 B |
**sql_planner — branch**
| Metric | Value |
|--------|-------|
| Wall time | 2475.5s |
| Peak memory | 131.2 MiB |
| Avg memory | 63.6 MiB |
| CPU user | 1881.6s |
| CPU sys | 1.4s |
| Peak spill | 0 B |
</details>
---
[File an issue](https://github.com/adriangb/datafusion-benchmarking/issues) against this benchmark runner
--
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: github-unsubscribe@datafusion.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For additional commands, e-mail: github-help@datafusion.apache.org
Re: [PR] Fix optimize_projections failure with struct-field join keys [datafusion]
Posted by "kosiew (via GitHub)" <gi...@apache.org>.
kosiew commented on code in PR #22903:
URL: https://github.com/apache/datafusion/pull/22903#discussion_r3425672760
##########
datafusion/optimizer/src/optimizer.rs:
##########
@@ -604,15 +617,14 @@ impl Optimizer {
while i < options.optimizer.max_passes {
log_plan(&format!("Optimizer input (pass {i})"), &new_plan);
- // Check once per pass whether the plan contains subquery
- // expressions. When there are no subqueries, we use the
- // cheaper `rewrite` traversal instead of
- // `rewrite_with_subqueries`, avoiding the per-node
- // map_subqueries call that walks all expression trees
- // via ownership-based transform_down.
- let has_subqueries = plan_has_subqueries(&new_plan);
-
for rule in &self.rules {
+ // Re-check for each rule: early rules can remove subquery
+ // expressions, allowing later rules to use the cheaper in-place
+ // traversal in the same optimizer pass. This is also
+ // correctness-sensitive: the in-place path refreshes parent
+ // schemas after child schemas change.
+ let has_subqueries = plan_has_subqueries(&new_plan);
Review Comment:
`plan_has_subqueries` now runs once per rule, even after it has already returned `false`. Correctness still looks fine, but for the common case where there are no subqueries, this changes the old once-per-pass scan into roughly one full plan scan per optimizer rule.
Could we cache the flag for the pass and refresh it only when a rule actually changes the plan? For example: `let mut has_subqueries = plan_has_subqueries(&new_plan);` and then `if transformed { has_subqueries = plan_has_subqueries(&new_plan); }`. That should keep the behavior where subqueries removed mid-pass are noticed, while still staying safe if a rule introduces a subquery.
--
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: github-unsubscribe@datafusion.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For additional commands, e-mail: github-help@datafusion.apache.org
Re: [PR] fix: optimize_projections failure with struct-field join keys [datafusion]
Posted by "alamb (via GitHub)" <gi...@apache.org>.
alamb commented on code in PR #22903:
URL: https://github.com/apache/datafusion/pull/22903#discussion_r3453193844
##########
datafusion/optimizer/src/optimizer.rs:
##########
@@ -518,10 +518,23 @@ fn rewrite_plan_in_place(
}
}
- // Recurse into children using Arc::make_mut (zero-cost when refcount == 1)
- changed |= map_children_mut(plan, |child| {
- rewrite_plan_in_place(child, apply_order, rule, config)
+ let mut child_schema_changed = false;
Review Comment:
This seems like it is potentially treating a symptom rather than the root cause 🤔
I worry this change may be ignoring the root cause elsewhere (an incorrectly reported "transofrmed" flag)
It seems like if the plan returns `transformed = false` the schema should not have changed.
--
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: github-unsubscribe@datafusion.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For additional commands, e-mail: github-help@datafusion.apache.org
Re: [PR] fix: optimize_projections failure with struct-field join keys [datafusion]
Posted by "kosiew (via GitHub)" <gi...@apache.org>.
kosiew commented on code in PR #22903:
URL: https://github.com/apache/datafusion/pull/22903#discussion_r3458674997
##########
datafusion/optimizer/src/optimizer.rs:
##########
@@ -518,10 +518,23 @@ fn rewrite_plan_in_place(
}
}
- // Recurse into children using Arc::make_mut (zero-cost when refcount == 1)
- changed |= map_children_mut(plan, |child| {
- rewrite_plan_in_place(child, apply_order, rule, config)
+ let mut child_schema_changed = false;
Review Comment:
@alamb,
> I worry this change may be ignoring the root cause elsewhere (an incorrectly reported "transofrmed" flag)
I think validating Transformed accuracy is worthwhile, but probably separate from this fix.
This PR intentionally continues to trust transformed; it recomputes parent schemas when a child rewrite reports changed = true and the child schema actually differs.
--
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: github-unsubscribe@datafusion.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For additional commands, e-mail: github-help@datafusion.apache.org
Re: [PR] Fix optimize_projections failure with struct-field join keys [datafusion]
Posted by "kumarUjjawal (via GitHub)" <gi...@apache.org>.
kumarUjjawal commented on PR #22903:
URL: https://github.com/apache/datafusion/pull/22903#issuecomment-4678640924
A subquery that survives decorrelation, such as an inequality-correlated scalar subquery over struct-field join keys, can still hit the stale-schema issue on the subquery traversal path. That plan shape cannot reach physical execution today, so I’m leaving it for a follow-up rather than expanding this PR.
Any feedback would be great.
--
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: github-unsubscribe@datafusion.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For additional commands, e-mail: github-help@datafusion.apache.org