Evaluate ClickHouse/ClickHouse#104431 (single-file Parquet parallelism) on ClickBench - #1436
Evaluate ClickHouse/ClickHouse#104431 (single-file Parquet parallelism) on ClickBench#1436alexey-milovidov wants to merge 8 commits into
Conversation
`clickhouse-parquet-104431` and `clickhouse-parquet-baseline` are copies of `clickhouse-parquet` whose `install` pins a specific RelWithDebInfo build from ClickHouse CI instead of downloading the latest release: - `clickhouse-parquet-104431` - head of ClickHouse/ClickHouse#104431 ("Parallelize reads from a single Parquet file in `StorageFile`, again"), `07303b95365362daace76759e4c51e39efefd25a`; - `clickhouse-parquet-baseline` - the master commit CI merged it into, `aec8b1d56234cdf035fcc0fc65afe31a9a0f224d`. Everything else - `queries.sql`, `create.sql`, `query`, the dataset - is byte identical to `clickhouse-parquet`, so the two directories differ only by the pull request. Not for merging: this is a measurement harness for one pull request. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…et-baseline (c6a.2xlarge, c6a.4xlarge, c6a.metal, c7a.metal-48xl, c8g.4xlarge, c8g.metal-48xl)
|
Results for Logs:
|
…et-baseline (c6a.large, c6a.xlarge)
|
Results for Logs:
|
…et-baseline (t3a.small)
|
Results for Logs:
|
… off
`clickhouse-parquet-104431-nosplit` runs the same pinned #104431 binary as
`clickhouse-parquet-104431`, with `input_format_parquet_min_bytes_to_split`
raised to 1 PB so no read clears the floor.
The decision still runs - the pull request computes the projected read size,
and so parses the footer, before comparing it against the floor - so the three
directories decompose the difference:
baseline -> nosplit cost of making the split decision
nosplit -> 104431 effect of actually splitting
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…into eval-ch-pr-104431
…rge, c6a.4xlarge, c6a.metal, c6a.xlarge, c7a.metal-48xl, c8g.4xlarge, c8g.metal-48xl)
|
Results for Logs:
|
|
Results for Logs:
|
Measurement harness, not for merging.
Evaluates ClickHouse/ClickHouse#104431
("Parallelize reads from a single Parquet file in
StorageFile, again") on ClickBench,on every machine type of the daily runs.
clickhouse-parquet-104431andclickhouse-parquet-baselineare copies ofclickhouse-parquetwhoseinstallpins a specific RelWithDebInfo build fromClickHouse CI instead of downloading the latest release:
clickhouse-parquet-104431PRs/104431/.../build_{amd,arm}_release07303b95365362daace76759e4c51e39efefd25a(pull request head)clickhouse-parquet-baselineREFs/master/.../build_{amd,arm}_releaseaec8b1d56234cdf035fcc0fc65afe31a9a0f224d(master)aec8b1d5is the honest A/B parent: ClickHouse CI built the pull request as the merge commite350489c26= "Merge07303b95into2a539919", and2a539919's only difference from itsparent
aec8b1d5is test files, so the binaries are source identical.2a539919itself has nobuild_amd_release- master CI skips that job - whileaec8b1d5has both architectures.Everything else (
queries.sql,create.sql,query,benchmark.sh, the dataset) is byteidentical to
clickhouse-parquet, so the two directories differ only by the pull request.Neither directory carries
results/, so nothing is added to the website.The pull request only changes the single local Parquet file path, which is what
clickhouse-parquetexercises. With the pull request's defaultinput_format_parquet_min_bytes_to_split = 2 GiB, 12 of the 43 queries splithits.parquetinto several sources atmax_threads = 16(Q21-Q24, Q28, Q29, Q34, Q35,Q37-Q40 - the ones reading
URL,TitleorReferer); the rest keep a single source, so theymeasure the cost of making the decision. The number of queries that split is expected to vary
with the machine's core count, which is why this runs on all nine machine types.