jayzhan211 opened a new pull request, #26644: URL: https://github.com/apache/datafusion/pull/26644
## Which issue does this PR close? - None. Test-only change to cut extended test CI time. ## Rationale for this change This cuts the fuzz suite, the largest part of the `extended_tests` job, to less than half its time. The job runs for every merge queue entry, 778 times in the last 30 days, so the saving adds up to roughly 30 runner-hours a month on 32-CPU runners. Most of the fuzz suite time is in `join_fuzz` (1606s of 2045s total test time locally), and inside `JoinFuzzTestCase::run_test` almost all of it is the nested loop join: | part of `run_test` | share of time | |---|---| | NestedLoopJoinExec | 73% | | formatting and sorting results | 23% | | HashJoinExec + SortMergeJoinExec | 4% | `run_test` loops over batch sizes `[1, 2, 7, 49, 50, 51, 100]`, which were picked to test sort-merge join batch boundaries (#2242). The nested loop join was later added inside the same loop as the reference result (#10728), so the reference is recomputed 7 times even though it does not depend on the batch size. Batch sizes 1 and 2 alone account for 70% of the `join_fuzz` time. ## What changes are included in this PR? `JoinFuzzTestCase::run_test` computes the nested loop join result once, with the default config, before looping over batch sizes. The hash join is still compared against it at every batch size, and the hash join vs sort-merge join comparison is unchanged. The nested loop join no longer runs at batch sizes 1, 2, 7, 49, 50 and 51 on fuzz data. Its unit tests already cover batch sizes 1, 2 and 16 for each join type. ## What is the testing strategy for this PR? This only changes a test. All 134 tests in the fuzz binary pass: ``` cargo nextest run --cargo-profile ci -p datafusion --features avro,backtrace,extended_tests,parquet_encryption --test fuzz ``` Local timing on 12 cores: | | before | after | |---|---|---| | fuzz suite wall time | 206s | 91s | | total test time | 2045s | 644s | | `join_fuzz` total test time | 1606s | 237s | The CI figure assumes the fuzz binary (about 4.5 minutes of the job today) drops by the same ratio. The merge queue's wall time does not change yet, because the microbenchmark job is still the longest required check. ## Are there any user-facing changes? No. -- 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]
