Add pgrust

[alexey-milovidov]

Adds pgrust, a rewrite of PostgreSQL in Rust targeting compatibility with Postgres 18.3 (AGPL-3.0, SELECT version() reports pgrust 18.3).

Setup

• Runs from the official Docker image malisper/pgrust:v0.1 (pinned launch release, multi-arch amd64+arm64), which is a drop-in replacement for the official postgres image. The container entrypoint applies the settings the upstream README requires (io_method=sync, max_stack_depth=60000, enlarged stack limits); no further tuning.
• create.sql and queries.sql are copied verbatim from the postgresql entry.
• Lifecycle scripts follow the cedardb pattern (Docker daemon, host psql, PGDATA on a host mount so data-size is a du including WAL). Uses the shared driver with BENCH_DURABLE=yes; true cold runs, so no lukewarm-cold-run tag. The concurrent QPS test is kept (process-per-connection daemon, like Postgres).

Complication: pgrust v0.1 cannot COPY the dataset as-is

COPY hits FROM 'hits.tsv' fails with invalid byte sequence for encoding "UTF8" even though the dataset is valid UTF-8 (verified byte-by-byte with iconv and Python). Root cause, isolated against both the Docker image and a source build:

• Whenever pgrust's 64 KiB COPY raw-buffer refill boundary falls inside a multi-byte UTF-8 character, encoding verification wrongly rejects the input. A 3000-line pure-Cyrillic file fails at line 1 blaming a perfectly valid З (0xd0 0x97); an equal-size pure-ASCII file loads fine; any line-aligned input ≤ 64 KiB (a single buffer fill) always loads.
• Client-side \copy fails the same way (wire-chunk boundaries instead of file-read boundaries).
• COPY ... WITH (ENCODING 'SQL_ASCII') also fails — impossible for a verifier that accepts every byte — so the defect is in the buffer bookkeeping around refills, not in the encoding verifier proper.

Workaround (documented in pgrust/README.md): load splits the TSV into line-aligned ≤ 64 KiB pieces (split -C 64k; max row in the dataset is ~6 KB, so pieces never oversize) and loads each with its own COPY statement, single session, single transaction, with FREEZE, then VACUUM ANALYZE. The data itself is not modified. Per-statement overhead measured at ~5-7 ms, which adds roughly an hour over a hypothetical single COPY for the ~1.2M pieces of the full dataset. A minimal reproducer and analysis are ready to be filed upstream.

Validation performed (1M-row sample)

• Split-load: 1,000,000 rows in 79 s via 11,952 COPY statements; Cyrillic round-trips correctly.
• All 43 queries pass, zero errors (including the regexp ones).
• VACUUM ANALYZE and in-transaction TRUNCATE + COPY ... FREEZE work.
• Data survives a fast-shutdown/restart cycle on the same data directory, and the entrypoint skips initdb when PG_VERSION exists — so the driver's per-query cold cycles (container recreation) are safe.
• Docker path verified separately: first-boot init, TCP password auth, server-side COPY from the /data mount, du-based data-size.

Expected performance

pgrust's own README says v0.1 is "not performance optimized" (their unpublished next version claims ~300x faster analytics). Concretely:

• Load: extrapolates to roughly 2-4 h on c6a.4xlarge (split + ~1.2M COPY statements + VACUUM ANALYZE).
• Queries: on the 1M-row sample on a fast 96-core machine, the slowest query (Q9) took ~11 s, several others 6-9 s — extrapolated to 100M rows on c6a.4xlarge, individual queries may run for many minutes, so the full sweep (43 × 3 tries plus per-query cold restarts and the 600 s QPS window) may approach or exceed the 10 h global benchmark timeout on smaller machines. If a run times out, the {"error": "<issue url>"} result convention applies; larger machines have a better chance of completing.

No results files yet — to be produced by system=pgrust ./run-benchmark.sh per machine.

🤖 Generated with Claude Code