scottlan0113 opened a new pull request, #19368: URL: https://github.com/apache/pinot/pull/19368
## Summary While investigating #10498 (part of the GROUP BY optimization tracking issue #11924), found two issues in `BenchmarkIndexedTable` that made the benchmark's results misleading: - `getNewRecord()` used a single `java.util.Random` field shared across all 10 worker threads. `Random` updates an internal seed via CAS, so under concurrent access this itself becomes a contention point unrelated to the `IndexedTable` implementations being benchmarked. In a JFR profile, `Random.next(int)` accounted for over half of all CPU samples, dwarfing the actual table operations. Switched to `ThreadLocalRandom`. - `NUM_RECORDS` (1000) was close to the key cardinality (100 x 100 = 10,000), so most upserts inserted a new key rather than updating an existing group. This doesn't exercise the repeated-group-update pattern typical of real GROUP BY workloads. Bumped to 100,000 so each group is hit roughly 100 times on average. ## Verification Ran an isolated before/after comparison (same cardinality, same JMH settings, only swapping `Random` for `ThreadLocalRandom`) to confirm the shared-`Random` issue was materially affecting results, not just a theoretical concern — the relative ordering of `concurrentIndexedTable` vs `simpleIndexedTable` flipped depending on which `Random` implementation was used. ## Test plan - [x] `mvn -pl pinot-perf compile` succeeds - [x] Ran `BenchmarkIndexedTable` locally and confirmed consistent results across multiple forks -- 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]
