Antalya 26.8: Parquet v3 read concurrency

[zvonand]

Changelog category (leave one):

• Performance Improvement

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

Parquet reader now fetches compressed chunks from storage far ahead of decoding. Compressed data is small, so many reads stay in flight while decoding catches up at its own pace — cold scans are no longer bottlenecked on storage latency (S3).
Read-ahead and decoding get separate memory and thread budgets, tunable via input_format_parquet_prefetch_memory_fraction (0.6) and input_format_parquet_decode_thread_fraction (0.375) (#2235 by @UnamedRus).

Cherry-picked from #2235.

---

Number of changes to bring parquet v3 reader perf closer to arrow based

[github-actions]

Workflow [PR], commit [11999f5]

[zvonand]

@blau-ai

[blau-ai]

CI triage for 11999f54

Verdict: 0 failures are caused by this PR. All red checks are pre-existing branch issues, known-flaky suites, infra timeouts, or a base-image CVE scan. The PR's own functional tests are green.

Head SHA: 11999f54fe0c3d399a2b691526ed43339ba5f6b1
Changed code: Parquet v3 reader (Reader, ReadManager, ReadCommon), two new Parquet format settings (FormatFactorySettings.h / SettingsChangesHistory.cpp / FormatSettings.h), Iceberg writes, plus two new 04616/04651_parquet_v3_* stateless tests.

Health check

The parts this PR actually exercises are healthy. Every functional stateless suite (amd_debug parallel/sequential, arm_binary, msan WasmEdge, distributed-plan s3, arm_asan_ubsan targeted, etc.) reports Failed: 0, and that includes the PR's own new tests 04616_parquet_v3_dictionary_filter_uncompressed_budget and 04651_parquet_v3_dictionary_filter_expanding_codec_budget (already adjusted in the last two commits). No Parquet-path failure appears anywhere in CI.

---

Per-failure breakdown

1. Grype Scan (keeper + server-alpine) — NOT PR-related
Grype Scan Completed with 1 high/critical vulnerabilities. This scans the built container image for CVEs in OS/base-image packages; it does not look at the PR's C++ changes. Affects every image on this base. → Handle via base-image/dependency bump; nothing to fix in this PR. Safe to ignore for merge.

2. Integration tests (amd_asan_ubsan, db disk, old analyzer, 2/8 & 5/8) — NOT PR-related (infra timeout, non-blocking)
Decisive log line:

!!!!!!! xdist.dsession.Interrupted: session-timeout: 7200.0 sec exceeded !!!!!!!
NOTE: Failed 1 tests - do not block pipeline, exit with 0
ERROR: session-timeout occurred during test execution

Every test that actually ran PASSED (test_storage_s3_queue, test_insert_into_distributed_sync_async, test_keeper_map, test_storage_iceberg_no_spark, …) — none touch Parquet reading. The shard simply hit the 2-hour wall-clock. The suite is explicitly marked do_not_block_pipeline_on_failure. → Safe to re-run; not a functional regression.

3. Stateless tests (arm_asan_ubsan, azure, parallel, 6/8) — NOT PR-related (flaky, non-blocking)
Failed: 1. The failing test is 02354_vector_search_rescoring_distance_in_select_list ("Reason: result differs with reference"). This is a vector-search test, unrelated to Parquet; the suite carries do_not_block_pipeline_on_failure: true and the test matches the known "random timeout with sanitizer" broken-test rule. → Flaky; safe to re-run.

4. Regression settings (aarch64 + release) — NOT PR-related (stale reference snapshot, branch-wide)
1842 scenarios (1836 failed) in ~3 min. The failures are [ Fail ] /settings/default values/<name> → AssertionError for essentially every setting, including ones that have nothing to do with this PR: ai_function_throw_on_error, allow_database_iceberg, allow_archive_path_syntax, allow_custom_error_code_in_throwif, … A Parquet-read-concurrency PR cannot change the default value of 1836 unrelated settings — this is the regression suite's expected-defaults snapshot being out of date for the 26.8 rebase (cf. #2404 "Fix test 04652: support Antalya build flavour in the settings history"). The server itself starts fine (13k+ stateless tests pass), so it is not a startup regression. → Fix belongs in the clickhouse-regression settings snapshot, not this PR.

5. Regression s3_azure_1 (aarch64 + release) — NOT PR-related
Failing scenarios are /s3/azure/part 1/disk/{remote host filter, syntax} and /s3/azure/part 1/invalid disk/{access default, access failed} — S3-over-Azure disk configuration/access tests, unrelated to Parquet format reading. Known environment-sensitive azure suite. → Pre-existing/flaky.

6. Regression tiered_storage_minio (aarch64, 1 failed) & clickhouse_keeper_no_ssl_1 (release, 7 scenarios) — NOT PR-related
Different subsystems (tiered storage / Keeper) with no overlap with the Parquet reader changed here. Consistent with the generally-flaky Altinity regression suites on this branch. → Pre-existing/flaky.

---

Suggested next step

No PR-side fix is warranted — none of the failures trace to the Parquet changes. To get a clean board:

• Re-run the Integration db-disk shards and the azure stateless 6/8 shard (timeout + flaky).
• The settings regression and the s3_azure/tiered_storage/keeper regression failures are pre-existing on antalya-26.8; they need attention in the regression harness / snapshots independently of this PR.
• Grype needs a base-image/dependency update, not a code change here.

(Analysis only — I have not pushed anything. I can't build/run ClickHouse in this container; the above is from the praktika S3 reports and the Actions job logs.)