For given query, usually threads will share the same MergeTreeReadPool. When the threads try to get task (MergeTreeReadPool::getTask), it is guarded by a mutex, if one thread is in the critical section, the others need to wait.

From our profiling, most of the cycles in getTask() is consumed by createTask() (about 70%), but it does NOT need mutex protection.

If we move createTask() out of the critical section, we see ~5% QPS gain in ClickBench Q1 & Q2 (Tested in Xeon 8380, 160 vCPUs, 2 sockets).

Changelog category (leave one):

• Performance Improvement

Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):

Reduce critical section in MergeTreeReadPool.

Documentation entry for user-facing changes

• Documentation is written (mandatory for new features)

Information about CI checks: https://clickhouse.com/docs/en/development/continuous-integration/

CI Settings (Only check the boxes if you know what you are doing)

All builds in Builds_1 and Builds_2 stages are always mandatory
and will run independently of the checks below:

• Allow: All Required Checks
• Allow: Stateless tests
• Allow: Stateful tests
• Allow: Integration Tests
• Allow: Performance tests
• Allow: All Builds
• Allow: batch 1, 2 for multi-batch jobs
• Allow: batch 3, 4, 5, 6 for multi-batch jobs

• Exclude: Style check
• Exclude: Fast test
• Exclude: All with ASAN
• Exclude: All with TSAN, MSAN, UBSAN, Coverage
• Exclude: All with aarch64
• Exclude: All with release
• Exclude: All with debug

• Run only fuzzers related jobs (libFuzzer fuzzers, AST fuzzers, etc.)
• Exclude: AST fuzzers

• Do not test
• Woolen Wolfdog
• Upload binaries for special builds
• Disable merge-commit
• Disable CI cache