Postgres 18 shows "Index Searches: N" in EXPLAIN ANALYZE output -- see commit 0fbceae841. This is the same information that has long been tracked by the pg_stat_*_indexes.idx_scan counter at the whole-index granularity, except that it is now also shown at the level of an individual index scan.
nbtree and GiST do the right thing with an unsatisfiable qual, such as "WHERE a = NULL": they never increment either counter. And so EXPLAIN ANALYZE shows "Index Searches: 0", given a query with such a qual. However, GIN and hash don't do things this way: they'll show "Index Searches: 1" instead. There is no principled reason for this inconsistency. I think that we should always show "Index Searches: 0" when any index AM determines that an index scan's qual is unsatisfiable. It just seems logical to me. After all, "index searches" implies that the index was physically scanned, but that's not what's going on with these problematic GIN/hash index scans. Is it worth correcting this inconsistency now? Technically this problem is nothing new -- the count shown by pg_stat_*_indexes.idx_scan has always worked this way. Showing the information in EXPLAIN ANALYZE just makes the inconsistency more noticeable. When I see "Index Searches: 0", I also expect to *not* see "Buffers: " output (at least not if there are repeat executions in the same backend, to account for syscache misses). Note on testing the behavior in this area: you may have to coax the planner into picking an index scan to show this behavior -- it'll generally prefer to use a Result node with "One-Time Filter: false" instead. I like to do this by using a prepared statement, while setting plan_cache_mode = 'force_generic_plan'. -- Peter Geoghegan
