2010YOUY01 commented on PR #18521: URL: https://github.com/apache/datafusion/pull/18521#issuecomment-3507379042
> > Thank you for the amazing work. > > Removing unnecessary consecutive `RepartitionExec` makes sense to me, however I have went through half of the test and found 2 plan changes that is not `2 RepartitionExec -> 1 RepartitionExec`, I'm wondering is that expected? Do we have other plan changes that is not removing 1 of the consecutive `RepartitionExec`? > > The first one see review comment. > > The second one is tpch-q4, I saw a 20% speedup in benchmark result, so I checked the query plan, and the difference is it's removing a round robin repartition above parquet reader: > > Can you calrify the data you used to create the tables, thank you I'm using tpch-sf0.1 dataset generated by https://github.com/clflushopt/tpchgen-rs/tree/main/tpchgen-cli `tpchgen-cli -s 0.1 --format=parquet` And register the dataset in `datafusion-cli` like <details> ``` CREATE EXTERNAL TABLE customer STORED AS PARQUET LOCATION '/Users/yongting/Code/datafusion-sqlstorm/data/customer.parquet'; CREATE EXTERNAL TABLE nation STORED AS PARQUET LOCATION '/Users/yongting/Code/datafusion-sqlstorm/data/nation.parquet'; CREATE EXTERNAL TABLE part STORED AS PARQUET LOCATION '/Users/yongting/Code/datafusion-sqlstorm/data/part.parquet'; CREATE EXTERNAL TABLE region STORED AS PARQUET LOCATION '/Users/yongting/Code/datafusion-sqlstorm/data/region.parquet'; CREATE EXTERNAL TABLE lineitem STORED AS PARQUET LOCATION '/Users/yongting/Code/datafusion-sqlstorm/data/lineitem.parquet'; CREATE EXTERNAL TABLE orders STORED AS PARQUET LOCATION '/Users/yongting/Code/datafusion-sqlstorm/data/orders.parquet'; CREATE EXTERNAL TABLE partsupp STORED AS PARQUET LOCATION '/Users/yongting/Code/datafusion-sqlstorm/data/partsupp.parquet'; CREATE EXTERNAL TABLE supplier STORED AS PARQUET LOCATION '/Users/yongting/Code/datafusion-sqlstorm/data/supplier.parquet'; ``` </details> This PR collected the HJ build side into a single partition, while previously it doesn't. I checked with ``` SET datafusion.explain.show_statistics = true; EXPLAIN ANALYZE... ``` And the statistics estimates the scan output row to be below `datafusion.optimizer.hash_join_single_partition_threshold_rows`, so the behavior is expected. Previously it's failing to follow the threshold for unknown reasons. I think the result is good, nothing to worry about. -- 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]
