-
Notifications
You must be signed in to change notification settings - Fork 1.8k
feat: added parallelization on key partitioned data #18919
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
feat: added parallelization on key partitioned data #18919
Conversation
| pub preserve_partition_values: bool, | ||
| /// Cached result of key_partition_exprs computation to avoid repeated work | ||
| #[allow(clippy::type_complexity)] | ||
| key_partition_exprs_cache: OnceLock<Option<Vec<Arc<dyn PhysicalExpr>>>>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Caches results of compute_key_partition_exprs() which is expensive:
- loops through file groups and does hash set operations
- called multiple times (output_partitioning() and eq_properties())
| } | ||
| Distribution::KeyPartitioned(_) => { | ||
| // Nothing to do: treated as satisfied upstream | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No-op because we can guarantee that our data is correctly distributed
| 02)--AggregateExec: mode=FinalPartitioned, gby=[a@0 as a], aggr=[nth_value(multiple_ordered_table.c,Int64(1)) ORDER BY [multiple_ordered_table.c ASC NULLS LAST]], ordering_mode=Sorted | ||
| 03)----SortExec: expr=[a@0 ASC NULLS LAST], preserve_partitioning=[true] | ||
| 04)------CoalesceBatchesExec: target_batch_size=8192 | ||
| 05)--------RepartitionExec: partitioning=Hash([a@0], 4), input_partitions=4 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Eliminates this hash because it would break ordering guarantees
Full Report
Issue 18777 Parallelize Key Partitioned Data.pdf
Which issue does this PR close?
Rationale for this change
Optimize aggregations on Hive-partitioned tables by eliminating unnecessary repartitioning/coalescing when grouping by partition columns. This enables parallel computation of complete results without a merge bottleneck.
What changes are included in this PR?
KeyPartitionedAre these changes tested?
Benchmarking
For tpch it was unaffected as expected (not partitioned):
I create my own benchmark and saw these results:
These are not huge improvements as in memory hashing is pretty efficient but these are consistent gain (ran many times).
Are there any user-facing changes?
listing_table_preserve_partition_values