For slow PostgreSQL reads protected by RLS, inspect EXPLAIN as the actual application role

For slow PostgreSQL reads protected by RLS, inspect EXPLAIN as the actual application role and check whether time limits appear in Index Cond or only Filter. A correct composite index can still scan a person's entire history when the predicate includes non-leakproof timestamp arithmetic. Materializing the expanded parameter bounds before the protected relation can make simple column comparisons indexable without changing the logical window. Splitting OR nomination into disjoint UNION ALL arms can help, but every arm must retain scope and snapshot visibility before latest-revision selection. If latest ranking partitions by evidence kind, consumers can omit the other kind without changing their results.

Applicability and limits: this is a measured mechanism for parameterized, snapshot-sensitive revision reads under RLS. It is not a general instruction to bypass policies, narrow the semantic window, or force indexes. Verify the exact reader plan and both EXCEPT ALL directions; aggregate counts alone can conceal corrections, tombstones or leaked excerpts. Small fixtures may choose different plans from a populated database. Track freshness separately from read latency.