Repository navigation
chore: Upgrade to datafusion 55 - #5634
Conversation
mdashti
left a comment
There was a problem hiding this comment.
Thanks for the PR! Two things I'd want resolved:
issue_4779 loses MPP. On c36e83a8 regress came back passed=299 failed=1. The expected plan has DistributedExec with Stage 1 ── tasks=3, partitions=9 and a NetworkCoalesceExec. This branch produces a flat single-process plan with no DistributedExec at all.
MPP dispatch may quietly lose its probe-side dynamic filters. DF 55 round-trips hashjoin.dynamic_filter (and the sort / aggregate ones) through proto. So on a worker the decoded HashJoinExec arrives with dynamic_filter already set, and the is_none() gate above makes gather_filters_for_pushdown skip pushing. PgSearchScanPlan::encode_for_dispatch doesn't ship its filters, and PhysicalPlanDecodeContext has no expression_id registry, so each decode creates its own Inner: the join's copy and the scan's copy end up separate instances with the same id. That would leave the relink pass in deserialize_physical_plan_with_runtime a no-op and the worker's scans unfiltered. EXPLAIN prints the leader's plan, so the mpp_* regress files wouldn't show it either way. Did you check that path? The same DF change also makes the "Once DataFusion round-trips the filters natively, this pass can go" note there stale.
Nothing tests the merge directly. Nothing drives handle_child_pushdown_result twice. So the only signal for a regression is the dynamic_filters=N count in the regress plans, and this PR (knowingly) makes that count wrong. A unit test that delivers the same filter on two passes and asserts the set stays at one would be great.
Stu's work in #5657 caused the same change, and we now know this is desirable.
I've added the correct proto converters, so this should be in a good place now.
I still need to address this. Ideally, the test would be able to examine the expression ids of the pushed-down filters between runs to assert the set is equivalent. |
A remapped wrapper shares its expression_id but carries a fresh pointer. The guard replaced only on pointer equality, so it dropped the remap that reflects the current tree shape and the scan kept stale column indices. Replace when the pointer differs.
# Conflicts: # Cargo.lock # nix/pg_search.nix
The fork upgrade merged to `main`, so pin its head rev instead of the mutable PR branch ref.
The df-d upgrade lowers the anti-join probe scan to one input partition. The `RoundRobinBatch(3)` above it still fans to 3, so downstream parallelism and results are unchanged.
# Conflicts: # nix/pg_search.nix
Track the immutable `snapshot-main-*` tag instead of a bare commit rev, matching how the fork is pinned on `main`.
…hat dynamic filters survive across fragments (#5766) ## What This PR fixes the performance regression show in the `join_semi_filter` alternatives 1 and 4 benchmark that was introduced by #5634. ## How During dispatch encoding and decoding, use the provided proto converter to encode/decode the dynamic filters. ## Tests The benchmark run in this PR shows the 50% perf improvement for the 2 `join_semi_filter` benchmarks.
Ticket(s) Closed
datafusion-55prerelease #5553What
Updates to pre-release DataFusion 55 and a DataFusion Distributed rev based on DF 55.
Why
DataFusion 55 has range partitioning functionality we need for future work.
How
Mostly update
cargo.tomland fix compile errors.There is one additional wrinkle: In DF 55,
HashJoinExecchanges its behavior to fix a bug (See this). That change assumes that installed dynamic filters remain installed between filter pushdown passes. This PR includes a change to make our handling of filter pushdown compatible by retaining filters between passes and de-duping by expression id. There is a lingering issue (#5635) from that, to be addressed later.Tests
HashJoinExeclit(true), so there are no correctness issues.null_awareto some lines.: