Transparent INSERT into compressed partitions (DML P1)

[SferaDev]

What

Removes the INSERT-side read-only limitation on compressed partitions. INSERTs (direct or routed through the parent) land in the partition heap at native heap speed — no decompression, no segment rewrite — and every read path unions the compressed segments with the uncompressed heap tail:

• DeltaXDecompress/DeltaXAppend gain a Phase 3 heap-tail scan (leader-only in parallel plans), with the full plan qual re-enabled when a tail exists (heap rows are never batch-filtered). A begin-time guard errors when a parallel plan could not drive the leader's copy (parallel_leader_participation=off) rather than dropping the tail.
• DeltaXCount/DeltaXMinMax fold loose heap rows into their metadata-derived results at exec time (under the executor snapshot), so those pushdowns stay enabled.
• DeltaXAgg bails to plain Agg over heap-tail-aware scans when any involved compressed partition has loose rows; a begin-time guard errors on the stale-cached-plan race instead of dropping rows.
• Top-N pushdown / pathkey claims are disabled at plan time when a tail exists; a custom-private marker + relcache invalidation on the heap's empty→non-empty transition catch stale cached plans (pathkeys → error, Top-N → silent fallback to the full scan).
• INSERT ... ON CONFLICT stays rejected (conflict inference cannot see rows inside segments) — including when smuggled in through a data-modifying CTE under a top-level SELECT. UPDATE/DELETE behavior is unchanged — they land in the follow-up P2/P2.5 PR.

deltax_compact_partition() folds loose rows into new segments appended to the existing companion tables (colstats/blooms/text_lengths/valbitmap kept exact or dropped, never under-covering) and truncates the loose region; the background worker compacts automatically each cycle. Compaction re-validates the catalog row under its AccessExclusive lock (closes a compact-vs-concurrent-decompress race), self-heals dead loose-row pages left behind by a REPEATABLE READ compaction (autovacuum is off on compressed partitions), and refuses json_extract tables with a clear remedy (decompress + recompress) instead of a raw SQL error.

Why

Compressed partitions were read-only; out-of-range or late-arriving data either errored or required manual decompress/recompress. With this change, a user inserting into a deltax table doesn't need to know whether the target partition is compressed — INSERT latency is plain-Postgres heap latency.

Design

dev/docs/COMPRESSED_DML.md (ships in this PR) carries the full DML program design (P1 heap-tail, P2 decompose-on-write, P2.5 tombstones).

Known tradeoff

Compaction ends with TRUNCATE of the loose region — like compress-time TRUNCATE, this is not MVCC-safe against a concurrent REPEATABLE READ reader whose snapshot predates the compaction commit (PostgreSQL's documented TRUNCATE caveat). This is the same tradeoff the existing compress path already makes; called out here for visibility.

Stacking

Based on fix/epoch-encoding (#33): this feature's plain-PG twin-table validation tests exposed those latent epoch bugs, and the heap-tail tests require the fixes to pass. Retarget to main once #33 merges.

Testing

• make build clean; make clippy zero warnings; cargo fmt --check clean
• make test (PG 17) and make test PG_MAJOR=18 green — 568 unit tests each
• make integration-test PG_VERSIONS=17 — 361/361 passed, including the new tests/test_compressed_insert.py (twin-table validation against plain PostgreSQL: routed + direct inserts, parallel scans, count/minmax folding, wCTE ON CONFLICT rejection, compaction, worker auto-compaction)

Provenance

Extracted from a longer perf session (branch perf/clickhouse-gap-session); UPDATE/DELETE (P2) and tombstone DELETE (P2.5) follow in a separate stacked PR. An independent correctness/cleanup pass tightened the stale-plan and compaction concurrency guards (see commit history).

[tsg]

This is a big one, we need it, but I want to do a bit of research myself on the possible approaches.