ShashidharM0118 commented on code in PR #19073:
URL: https://github.com/apache/datafusion/pull/19073#discussion_r2624191164
##########
datafusion/core/src/physical_planner.rs:
##########
@@ -1599,6 +1603,25 @@ impl DefaultPhysicalPlanner {
}
}
+fn has_sufficient_rows_for_repartition(
+ input: &Arc<dyn ExecutionPlan>,
+ session_state: &SessionState,
+) -> Result<bool> {
+ // Get partition statistics, default to repartitioning if unavailable
+ let stats = match input.partition_statistics(None) {
+ Ok(s) => s,
+ Err(_) => return Ok(true),
+ };
+
+ if let Some(num_rows) = stats.num_rows.get_value().copied() {
Review Comment:
Thanks for the suggestion! Using
`datafusion.optimizer.repartition_file_min_size` makes much more sense. It's
more general since it works for all data sources with `total_byte_size`, not
just row-based stats. It's also more accurate since byte size better reflects
repartition cost, and it's consistent with the existing file scan
repartitioning config.
Before I proceed, I have a few questions:
1. Should I add a getter in `SessionConfig` to access
`repartition_file_min_size`, or is there an existing way to access it?
2. Compared to the current changes, using file size will likely affect 50+
test plan and answer files including TPCH, group_by, joins, subqueries, and
others. Is that acceptable, or should I update them in stages?
3. The default `repartition_file_min_size` is 10MB. Is that reasonable for
aggregates, or should we consider a different value?
Would appreciate any guidance on the best approach here. Thanks!
--
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]
