beliefer opened a new pull request, #38388: URL: https://github.com/apache/spark/pull/38388
### What changes were proposed in this pull request? Currently, if the creation side of bloom filter could be broadcasted, Spark cannot inject a bloom filter or `InSunquery` filter into the application side. I think at first we thought broadcast was cheaper than runtime filter. This behavior is contrary to the join has a shuffle below broadcast hash join described in the design document.  In fact, we can inject bloom filter which could reuse the broadcast exchange and improve performance. As we know, bloom filter ensures creation side is small enough with the code below. ``` // Skip if the filter creation side is too big if (filterCreationSidePlan.stats.sizeInBytes > conf.runtimeFilterCreationSideThreshold) { return filterApplicationSidePlan } ``` `InSunquery` filter ensures creation side is small enough with the code below. ``` val aggregate = Aggregate(Seq(alias), Seq(alias), filterCreationSidePlan) if (!canBroadcastBySize(aggregate, conf)) { // Skip the InSubquery filter if the size of `aggregate` is beyond broadcast join threshold, // i.e., the semi-join will be a shuffled join, which is not worthwhile. return filterApplicationSidePlan } ``` ### Why are the changes needed? 1. Relax the restrictions of broadcast join on bloom filter, so as the runtime filter applicable to more scenarios. 2. Reuse the broadcast exchange for bloom filter. ### Does this PR introduce _any_ user-facing change? 'No'. Just update the inner implementation. ### How was this patch tested? New tests. -- 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]
