Match CHECK constraint exclusion planning speed (per-plan compilation + backend summary cache)

[bitner]

Goal of this branch: make non-key pruning as cheap to plan as PostgreSQL's own constraint exclusion. Done — table_range now plans on par with (warm, slightly faster than) CHECK constraint exclusion, via two optimizations grounded in a review of the Postgres source.

How constraint exclusion works (the target)

relation_excluded_by_constraints → get_relation_constraints (plancat.c) reads each partition's CHECK from the relcache (rd_att->constr->check) via table_open(relid, NoLock) — the partition is already locked and cached, so it does zero extra I/O per partition — then proves contradiction with predicate_refuted_by (predtest.c) on in-memory expression trees. Per-partition cost ~5 µs.

Where our time went (measured)

A diagnostic attribution at 2,000 partitions split our original ~31 µs/partition: the index-page read was only ~7 µs; evaluation was ~23 µs, dominated by work identical across all partitions but redone per partition — btree_strategy catalog lookups, getTypeInputInfo/fmgr_info setup inside every parse/compare, and constant rendering.

Two optimizations

1. Per-plan compilation (commit 1). Resolve the compare function, type-input function, and operator strategy once per plan (cached FmgrInfos + memos), reused across partitions. Planner-only; the aminsert path keeps the uncached helpers. → ~88 ms → ~43 ms; eval becomes effectively free.

2. Backend summary cache (commit 2, src/summary_cache.rs). Cache each index's deserialized summary for the life of the backend, so warm/repeated plans skip the per-partition index open + metapage read + deserialize entirely (shared via Rc with the per-plan cache). Coherence rests on the over-inclusive invariant: a cached summary is safe unless it is narrower than reality. Only aminsert widens; when it does it sends a relcache invalidation, and a registered callback drops the cached copy everywhere — locally at the next command boundary, in other backends at the widening transaction's commit (matching row visibility). Narrowing operations (delete, vacuum re-tighten) need no invalidation. Widen-invalidations are coalesced to one per index per transaction so bulk loads don't thrash. → ~43 ms → ~34 ms.

Result (2,000 partitions, warm, same session)

	Planning
CHECK constraint exclusion	~37 ms
table_range before this branch	~84 ms
table_range after	~34 ms
no pruning (baseline expansion)	~26 ms

Per-partition planning cost fell from ~31 µs → ~3–4 µs — on par with constraint exclusion, and warm we actually beat it (we serve a cached summary; constraint exclusion re-parses each CHECK every plan). At 300 partitions, pruning-on planning (~4 ms) is now ~equal to pruning-off. A cold first plan still reads each page; every plan after is cached.

29 tests pass (including the insert-correctness tests, which exercise widen→invalidate); production build, clippy, and fmt clean. README performance/scaling sections and bench/benchmark.sql updated, including the CHECK constraint-exclusion comparison.

Tradeoff (documented)

The cache benefits read-mostly/repeated planning. For append-heavy workloads where nearly every insert widens the summary, the per-widen relcache invalidation is real cost (coalesced per transaction). Correctness is unconditional; the perf benefit is workload-dependent.