No index usage collection for PostgreSQL, where an unused index costs more than on SQL Server

[erikdarlingdata]

Part of #2530.

The gap

Nothing collects pg_stat_user_indexes (or pg_stat_all_indexes). SQL Server users already get get_index_usage; PostgreSQL users get nothing equivalent.

idx_scan, idx_tup_read and idx_tup_fetch are the whole story for "is this index earning its keep", and pg_stat_user_indexes joined to pg_class gives the size to weigh it against.

Why it matters more here than on SQL Server

On SQL Server an unused nonclustered index costs write throughput and space. On PostgreSQL it costs the same plus it participates in every VACUUM — index cleanup is a large share of vacuum work, so dead indexes directly slow the maintenance that #2530's Vacuum surface exists to monitor. An unused index on a hot table is a vacuum problem as much as a write problem.

It is also the cheapest tuning advice a monitoring tool can give: dropping an index nobody scans has no downside to model.

Notes

• idx_scan is cumulative since stats reset. stats_reset on pg_stat_database (Collect pg_stat_database: temp-file spills, cache hit ratio, deadlocks and commit ratio in one read #2539) is the way to tell "never scanned" from "reset yesterday" — worth doing after that one so the distinction is available, because reporting a freshly-reset index as unused is exactly the wrong advice.
• Index size wants pg_relation_size, and on a large database that is not free — check what PgAutovacuumStatsCollector already does about relation sizing rather than inventing a second approach.
• Partial and expression indexes read as unused when the planner cannot match them; the read should carry enough (indexdef) that a human can tell "unused" from "unusable".