FFORGE//RS
← Roadmap

distributed systems / LEVEL 4

The index that starts with the range

EST.50 MIN
01

THEORY / RETRIEVAL

What to restore

  • Order B-tree keys from leading equalities to range and ordering columns
  • Use partial and INCLUDE columns only when the query contract justifies them
  • Connect VACUUM and the visibility map to index-only scan behavior

B-tree key order follows access shape

Leading equality predicates constrain a multicolumn B-tree most effectively; the first non-equality key can then serve a range or ordering requirement. A partial index is usable only when the query predicate implies its predicate. INCLUDE may cover returned data but increases write and storage cost.

An index-only plan still depends on MVCC maintenance

PostgreSQL indexes do not carry tuple visibility for normal snapshots. Index-only scans consult the visibility map and may still fetch heap pages. Routine VACUUM reclaims reusable dead-tuple space, updates visibility information and prevents transaction-id wraparound; VACUUM FULL is a blocking rewrite, not routine medicine.

CHECKPOINT

For `WHERE tenant_id=? AND status=? AND created_at>=? ORDER BY created_at DESC`, which B-tree key order best matches the leading equality and range shape?

ISOLATED RUST 1.96
src/lib.rsEDIT

02 / CODE REVIEW

Make the code safe

Repair the Rust index advisor for the documented query family. Tenant equality is always present; an optional status equality comes next; created_at is the range/order key. A partial active index is legal only for a literal active predicate, and payload is included only when returned.

Initializing editor…
CLOUD SANDBOXnetwork off · 256 MB · 12 s
1 / 64 KB
OUTPUT
Runner is waiting for a submission.