storage.files carried 13 indexes; every INSERT/DELETE/rename maintains all of
them. Two are never chosen by the planner for any query the app issues —
verified statically (query text) AND empirically on a 50k-row table via
EXPLAIN + pg_stat_user_indexes over the real query shapes (idx_scan = 0):
- idx_files_name_search (user_id, name text_pattern_ops): file-name search is
`name ILIKE '%term%'` (served by the GIN trgm index); text_pattern_ops can
serve neither ILIKE, a leading-% substring, nor default-collation ORDER BY.
The one exact `name = $1` lookup is `WHERE folder_id=$1 AND name=$2`, served
by the UNIQUE (folder_id, name, user_id) index.
- idx_files_category_order (category_order): only emitted as a derived
type_order alias inside the folders⊎files UNION-ALL listing; the ORDER BY
runs post-UNION, so a single-column files index can't presort it. The real
listing uses idx_files_folder_id + a top-N sort.
Benchmark (50k single-row inserts, all triggers active): ~6% faster
(WITH: 10.46/10.71s; WITHOUT: 9.83/10.07s — every WITHOUT run beat every WITH
run) plus less disk and WAL on every file mutation. No query regression: the
planner never used these indexes. Reversible.
idx_folders_path (path text_pattern_ops) is intentionally KEPT — it serves
exact `WHERE path = $1` equality lookups.
https://claude.ai/code/session_01DCszkkU11LYxMEUWr4setK
Claude
ecbb4ec834