# P0 eager-RLS baseline: 1M rows per source mapping

Date: 2026-08-12  
Commit: `577ef2a` plus the uncommitted P0 benchmark/test checkpoint  
PostgreSQL: 17, local Apple Silicon development build  
Profile: `RUN_PROFILE=compact`, `SAMPLES=1`, `WARMUPS=0`,
`graph.query_memory_mb=1024`

## Fixture

- 1,000,000 scalar-key node rows
- 1,000,000 composite-key node rows
- 999,999 standalone relationship rows
- 2,000,000 projected nodes and 1,999,998 directed edges
- build time: 111,477 ms
- reported projection memory: 176.25 MiB
- source relation sizes: 107,003,904 bytes scalar nodes, 116,080,640
  bytes composite nodes, and 82,771,968 bytes relationship rows

## Result

The no-RLS depth-zero control completed in 3,712 ms. The development visibility
metric reported 9 microseconds, zero hidden nodes, and zero hidden relationships;
the remaining time includes query start and loading the persisted backend-local
projection.

The first node-RLS broad-allow depth-zero query did not finish after more than
600 seconds and was cancelled manually. PostgreSQL returned query-cancelled and
the backend remained usable. This is a censored lower bound, not a completed
latency sample.

The eager builder scans every RLS-active registered source mapping before seed
resolution. In this fixture one targeted depth-zero query therefore scans the
million-row scalar and composite node mappings even though it requests one
scalar identity. The observed result is sufficient to reject eager full-source
visibility as the scalable targeted-query strategy.

## 10M decision

A 10M-per-mapping graph profile was not executed on this workstation. The 1M
RLS query already exceeded ten minutes and the 2M-node projection used 176 MiB
before query workspace. Extrapolating this eager implementation to 10M would
consume substantial local time and memory without changing the architectural
decision. The benchmark runner retains a parameterized 10M soak profile for a
dedicated benchmark host. P5 must produce completed 1M and 10M lazy/eager
comparisons before the scalable strategy can ship.

Exact SPI-call, key-scan, and byte-scan counts are recorded as unavailable in
the runner until dedicated instrumentation exists; this checkpoint does not
infer them from elapsed time.

`observations.csv`, `database-metadata.csv`, and `run-metadata.txt` retain the
values recorded during the manual run. The original per-statement log, exact
unrounded timing sample, and source `EXPLAIN` plans were not retained, so this
directory does not fabricate them after the fact. The hardened runner now
retains those artifacts automatically, including on statement timeout.