comphead commented on PR #23167: URL: https://github.com/apache/datafusion/pull/23167#issuecomment-4794729286
Thanks @avantgardnerio this is challenging task, some insights how Spark AQE does the same Spark plans a shuffle join initially, lets the input shuffle map stages actually run, reads the byte counts that came out of those stages, and then re-runs the optimizer + planner on the still-unexecuted portion of the plan with those real numbers in hand. Because the size is now real instead of estimated, the planner's normal `JoinSelection` strategy can flip a `SortMergeJoinExec` into a `BroadcastHashJoinExec` — the rule that picks broadcast is the same rule the non-AQE planner uses; what's different is the stats it sees. Spark is able to identify if relationship is large or small based on the shuffle size, data which available in runtime before the join. For proposed approach I'm probably missing the part to identify size of relationship? if the first batch is a small batch and subsequent are large ones, what decision would be made? @thinkharderdev Reg to stats, are they calculated on runtime? if one of the relationship is filtered/generated table, how rowcounts calculated for partition stats? -- 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]
