Question

We have a busy PostgreSQL 9.5 server with OLTP-like traffic where pg_stat_all_tables.idx_scan values go up with considerate rate while we're having performance problems.

Does that (idx_scan increasing) actually mean that

  1. the system is actually running lots of full scans through indexes (meaning, reading the whole index from the disk if not already in the cache), or
  2. the system is actually getting some only some tuples ("rows") from those indexes (that is, using the index as intended)?

If the option 1 is true, how to figure out how to get system into state 2? Do I need some additional indexes or are some of my queries bad? All queries get nice performance while the system is under low load but during very high load pretty much any query can get unexpectedly poor execution time.

(The documentation at https://www.postgresql.org/docs/current/monitoring-stats.html only says "Number of index scans initiated on this table".)

Was it helpful?

Solution

Whenever an index is used, that counts as an index scan. There is no separate counter for full index scans. You could compare idx_scan to idx_tup_fetch and see how any rows are returned from the index per scan on average. But what is the point? For the most part, it fetches the number of rows it needs to in order to do the job you assigned it. Maybe you are missing an index that could do the job better, but looking at this stat will not tell that that is the case, nor tell you what hypothetical index that might be.

I do a lot of performance investigation and almost never look at those values, unless I'm trying to tune/debug autovac. EXPLAIN (ANALYZE, BUFFERS), pg_stat_statements, auto_explain are the right tools for the job.

Licensed under: CC-BY-SA with attribution
Not affiliated with dba.stackexchange
scroll top