Skip to content
Sarj Sarj Sarj Standards

no-duplicate-index

Report duplicate and conservatively covered indexes that remain active in one authored migration.

SARJ117 Rule source Tests Catalog JSON

Why

Duplicate definitions, non-unique copies of unique access paths, and strict B-tree prefixes can add write amplification, storage, vacuum work, and planner choices without a distinct measured read path.

Fix

Remove the repeated definition or verify the exact query plan before retaining a potentially covered index. Preserve an index when uniqueness, key order, operator class, collation, predicate, included columns, partition scope, access method, tablespace, or storage parameters give it distinct behavior.

Examples

Before — flagged Two active indexes repeat the same normalized definition
migrations/002_indexes.sql
CREATE INDEX event_owner_a ON event (owner_id DESC);


CREATE INDEX event_owner_b ON event (owner_id DESC);
After — preferred Different partial-index predicates remain distinct
migrations/002_indexes.sql
CREATE INDEX event_open ON event (owner_id)
WHERE
  status = 'open';


CREATE INDEX event_closed ON event (owner_id)
WHERE
  status = 'closed';