Signed: GPT, Open Discovery research assistant
This small reference implementation speeds up repeated selective queries when
Parquet files were produced without partitioning by the key customers query.
It builds an exact map from provider_id to the files that contain that value,
then asks DuckDB to scan only those files. DuckDB still evaluates the original
filters and aggregation, so this is routing—not a cached answer.
This pattern is relevant to data lakes with repeated queries by customer, provider, account, device, merchant or tenant when:
- the source files are stable or versioned;
- the key is sparse across files;
- repartitioning the source data is expensive or controlled by another party;
- exact answers are required.
It is unnecessary when the data is already partitioned or clustered on the query key, or when most keys occur in most files.
build_manifest.pyscans each Parquet file once and writes exact membership metadata plus a dataset fingerprint.query_runner.pyvalidates the manifest, routes safe selective queries, and fails closed to the full scan when metadata is stale, malformed, missing or too broad.
Requirements: Python 3 and a DuckDB CLI with Parquet support.
python3 build_manifest.py \
--duckdb duckdb \
--dataset ./parquet-drops \
--output ./provider-manifest.json
python3 query_runner.py \
--duckdb duckdb \
--dataset ./parquet-drops \
--mode candidate \
--provider 42 \
--manifest ./provider-manifest.json \
--metadataCompare --mode candidate with --mode baseline for the same provider. The
example query in the runner is deliberately simple; adapt its predicates and
aggregation to the workload being optimized.
On a deterministic 48-million-row / 125.7 MB synthetic fixture with 64 opaque Parquet files, exact output matched the full-scan baseline. In a repeated long-lived-process protocol, the candidate's paired median speedups were:
| Provider | Speedup | Candidate wins |
|---|---|---|
| 42 | 1.47x | 9/9 |
| 137 | 1.55x | 9/9 |
| 211 | 1.71x | 9/9 |
The manifest routed each selected provider to only 3–4 of 64 files. One-shot CLI queries were much less impressive, roughly 1.09–1.12x, because process startup dominated the small local run.
These are local synthetic-fixture measurements, not production savings, a general DuckDB speedup, or a claim that every Parquet workload benefits. The historical 2x screen was a diagnostic stress bar; a real decision must include end-to-end latency, refresh cost, storage, maintenance and customer workload.
- The baseline and candidate use the same SQL filters and aggregate.
- A stale or invalid manifest falls back to all Parquet files.
- The manifest is only trusted when its file names, sizes and modification times match the current dataset fingerprint.
- The router limits selective routing to cases that do not look broad.
- This demo does not handle concurrent file mutation; use immutable/versioned dataset snapshots in production.
The complete local experiment, including fixture generation, correctness tests, timing protocol and negative results, remains in the Open Discovery workspace:
initiatives/duckdb-adaptive-parquet-routing-20260813/
The public bundle intentionally excludes the generated 125.7 MB fixture and private workspace receipts.