Add duckdb-vortex-tuned: variant with threads=2 for memory-constrained hosts

[KazukiKandaKK]

Adds duckdb-vortex-tuned/ as a variant of duckdb-vortex/, following the existing postgresql / postgresql-indexed and pinot / pinot-tuned splits.

Why a separate directory

On this run's host (AWS c6a.xlarge, ~7.6 GiB usable RAM), duckdb-vortex's default recipe (threads=4, untouched) does not complete: COPY 'hits.parquet' TO 'hits.vortex' (FORMAT vortex) gets OOM-killed by the kernel before any of the 43 queries run, and lowering memory_limit alone doesn't prevent or delay it. Only reducing threads (to 2 or 1) let the conversion finish. Root-cause investigation is filed upstream at vortex-data/vortex#10046 (open, unresolved); that thread also links to vortex-data/vortex#9674, a broader in-progress effort to make Vortex's buffer allocations accountable to the host engine, which isn't yet wired up on the DuckDB write path.

Per this repo's README (vanilla and tuned results should be reported as separate entries, e.g. "MyDatabase" and "MyDatabase-tuned"), this is duckdb-vortex-tuned/ with "tuned": "yes", not an overwrite of duckdb-vortex/. Unlike pinot/pinot-tuned, which share machine types (e.g. c6a.4xlarge) so the site shows both side by side, duckdb-vortex/results/ has no c6a.xlarge.json for any date and, per the above, can't get one on this specific machine. So duckdb-vortex-tuned/c6a.xlarge.json will appear without a matching vanilla entry.

What's different from duckdb-vortex/

load adds SET threads = 2; before the COPY conversion. Every other script (benchmark.sh, queries.sql, install, start, stop, query, check, data-size, create.sql) is byte-identical to duckdb-vortex/ (checked with diff).

threads=1 also completed and was faster (load_time 1,439.9s vs. 1,540.3s, n=1 each). threads=2 is used here because it's the largest value that still completes, not because it's faster — this PR favors the smallest deviation from default over chasing an unreplicated speed difference.

Result

c6a.xlarge, 2026-09-25, DuckDB v1.5.5. Full 43-query x 3-run timing matrix (cold + 2 hot), no nulls. load_time is the benchmark driver's wall-clock measurement of load (lib/benchmark-common.sh's bench_load), rounded to whole seconds per convention; data_size is du -bcs hits.vortex. Concurrent phase is skipped (BENCH_CONCURRENT_DURATION=0, already set in duckdb-vortex's own benchmark.sh for single-process engines, see #946), so concurrent_qps/concurrent_error_ratio are null, matching duckdb-vortex's own results.

[github-actions]

Results for duckdb-vortex-tuned are ready for: c6a.2xlarge, c6a.4xlarge, c6a.metal, c7a.metal-48xl, c8g.4xlarge, c8g.metal-48xl.
The result files are committed as 168ab33.
Removed manually added result files: duckdb-vortex-tuned/results/20260925/c6a.xlarge.json.
The run of duckdb-vortex-tuned on c6a.large did not produce results.
The run of duckdb-vortex-tuned on c6a.xlarge did not produce results.

Logs:

• duckdb-vortex-tuned on c6a.xlarge: benchmark log, cloud-init log
• duckdb-vortex-tuned on c6a.4xlarge: benchmark log, cloud-init log
• duckdb-vortex-tuned on c6a.metal: benchmark log, cloud-init log
• duckdb-vortex-tuned on c6a.2xlarge: benchmark log, cloud-init log
• duckdb-vortex-tuned on c7a.metal-48xl: benchmark log, cloud-init log
• duckdb-vortex-tuned on c8g.4xlarge: benchmark log, cloud-init log
• duckdb-vortex-tuned on c8g.metal-48xl: benchmark log, cloud-init log
• duckdb-vortex-tuned on c6a.large: benchmark log, cloud-init log

[github-actions]

The run of duckdb-vortex-tuned on t3a.small did not produce results.

Logs:

• duckdb-vortex-tuned on t3a.small: benchmark log, cloud-init log