perf(db): bound since-limited events reads with the month-floor literal - #9197

Summary

A newest-first events read whose own since is at or above the recent-pass floor now runs as a single recent pass. Postgres prunes it to the recent monthlies at plan time instead of locking every partition. Results are unchanged.

Why. split_for skipped any read whose since was at or above the floor (since_prunes), on the theory that its since already prunes. It does, but only as a bind parameter. Once a prepared statement switches to a cached generic plan, Postgres prunes bind-parameter bounds at execution, after AcquireExecutorLocks has already locked every events partition and its indexes. Live REQs with a recent since are this shape, for example #p mention reads from reconnecting agents. Under load they spill past the 16 fast-path lock slots and contend on LWLock:LockManager. The ceiling PR (#9157) named this gap as identified debt.

What changes. Such a read now gets the same Split as other recent reads, so the recent pass carries the floor literal (plus the ceiling literal for regular-kind reads) on e.created_at and on m.event_created_at for #p. Split gains older: bool. It is false when the read's own since is at or above the floor, because no row below the floor can match, so no older pass follows a short recent pass. A read whose until falls below the floor stays unsplit, as before.

No protocol, schema, index or client change.

Related issue

Follow-up to #9157 (its identified debt: bind-parameter since reads).

Testing

• recent_pass::tests::split_eligibility: the table now records not split / ceiled / open and whether an older pass follows. New rows: since at the floor, a recent since with regular, any and addressable-only kinds, and a recent since with until below the floor.

• recent_pass::tests in-memory exactness: adds a since-at-floor split that runs exactly one pass and returns the rows at or above the floor.

• postgres_tests::since_bounded_mention_read_locks_only_recent_partitions (new): runs partition maintenance, inserts #p rows at the floor, now, one second below the ceiling and one day below the floor, then reads with since = floor. The production path returns the three recent rows through the mention join. Under plan_cache_mode = force_generic_plan the recent pass locks only the partitions holding those rows. The unsplit read locks every partition.

• The partition-lock helper from perf(db): stop the events recent pass at a ceiling for regular-kind reads #9157's test is now shared by both lock tests.

• Diagnostic on Postgres 17.11 with the 19-partition layout partition maintenance keeps, for a #p read with since at the floor (not committed):

  	events partitions locked	Relation locks	Non-fast-path locks
  Before (bind-only since, generic plan after five runs)	19	26	10
  After (floor and ceiling literals)	2	9	0

  EXPLAIN (GENERIC_PLAN) before appends all 19 partitions. After, it appends only the previous and current monthlies.

Mutation-checked on Blox. Each of these fails the new Postgres test or the unit tests: removing the since_prunes split, ignoring older, and dropping the e. literal.

What got simpler

Nothing got simpler. The change adds one flag to the existing Split type and no new concept. The duplicated partition-lock reader in the #9157 test became one shared helper.

🤖 Generated with Claude Code