upgrade to datafusion 55#540
Conversation
introduces the proto converter to the PhysicalExtensionCodec trait which helps dedupe dynamic filters
|
TPCH For queries that got faster, I would expect that they have local dynamic filters, which should work in this branch. Also, I could actually try to run individual queries with metrics but I'm not sure if it's worth the time since the overall diff is 1.01x faster.
TPCDS |
|
@gabotechs What do you think about the benchmarks above? Unremarkable? I'm not sure if it's worth analyzing why things are slow or fast because on average, the improvement is 1x. Seems like the variance is high though. Some queries are 30-40% faster, some are 30-40% slower. I ran these with |
|
I see them within the typical noise. You can try running them with Typically, the most relevant bits you want to look at for overall performance are these: So with those benchmarks my read is that there's just no impact on performance. |
Goal
Closes #530
I would like to create a development branch to work on dynamic filtering. Datafusion 54, which is currently used in
maindoes not have this change: apache/datafusion#21055.This PR aims to create a development branch using apache/datafusion@01bf68c, which is the latest commit on
apache/datafusion:mainas of writing.Once Datafusion 55 releases, we update this PR to the correct SHA and merge it in to
datafusion-distributed:main. Hopefully the changes will be minimal because we already have all datafusion 55 changes up to apache/datafusion@01bf68c.Summary of Significant Changes
In
src/protobuf/distributed_codec.rswe now use theproto_converterargument during serde to ensure dynamic filters retain referential integrity. This automatically makes dynamic filters work.Distribute byte ranges across partitions: feat: lower repartition_file_min_size default from 10 MiB to 1 MiB apache/datafusion#22439
repartition_file_min_sizefrom 10 MiB to 1 MiB. The PR explicitly calls out TPC-DS SF1 dimension tables. Files may be duplicated across multiple partitions where but each partition reads a different byte range (this is hidden by ...., but we know from the correctness tests that nothing broke). A lot of tpcds queries now split acrosstarget_partitionsinstead of staying under-partitioned. In thetpcdsplan tests, we usetarget_partitions=3.Example:
dynamic_rg_pruning=eligibledisplay changes feat(parquet): intra-file early stopping via statistics + dynamic filters apache/datafusion#22450dynamic_rg_pruning=eligibleto leaf nodes. Lots of snapshots change because of this._inject_network_boundaries, we would assume that every CollectLeft HashJoin can be broadcast. So, I added some code (look forcollect_left_hash_join_requires_single_task) to check for aBroadcastExecbefore committing to doing a broadcast join. Without this change, correctness tests fail. I honestly think we previously did not have good coverage forLeftSemi, which is why this bug never appeared before.LeftSemibe broadcast? A left semi join means "emit a row on the left side of the join if it matches any row on the right". You cannot broadcast the left side of aLeftSemijoin because you duplicate the left side across tasks, which may result in duplicate rows.Example: See TPCDS query 1 (note the new
LeftSemijoin)