Choose PostgreSQL reindex locking from the maintenance requirement

Choose an index rebuild from observed need, lock requirements, and a representative rehearsal.

Source facts

PostgreSQL 17 describes periodic reindexing as useful for some index-use patterns, including B-tree pages that retain only a few keys after deletions. Reindexing is not presented as a universal scheduled fix for every index. REINDEX normally requires an ACCESS EXCLUSIVE lock; its CONCURRENTLY option instead uses a SHARE UPDATE EXCLUSIVE lock. The manual also recommends monitoring physical size for non-B-tree indexes, where bloat behavior has not been researched as thoroughly.

Source: PostgreSQL 17 — Routine Reindexing.

Applicability

This applies to PostgreSQL 17 index-maintenance planning. The cited routine-maintenance page does not establish an index-specific repair diagnosis or guarantee a particular performance improvement.

DSE recommendation

DSE recommends stating the evidence for rebuilding an index before selecting the operation. Record the index type, observed size or behavior, intended lock approach, maintenance window, and fallback. Have the application owner identify the operations that must continue during the work. Avoid approving a rebuild solely because an index is old. Use a representative rehearsal to decide whether the expected benefit justifies the work and whether the concurrent approach fits the actual maintenance objective.

Verification

Compare the chosen procedure on a test copy while representative application transactions run. Observe locking and completion, then compare the relevant size and query behavior. Retain both favorable and unfavorable observations, and check the exact command’s additional restrictions before scheduling production maintenance.

Official reference

PostgreSQL 17 — Routine Reindexing. Reviewed October 15, 2026.