Re: pg_stat_all_indexes understand

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Nicolas Paris <niparisco(at)gmail(dot)com>
Cc: pgsql-performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: pg_stat_all_indexes understand
Date: 2015-07-09 16:45:25
Message-ID: CAMkU=1wvRL88u_X0DSc78_TTCji0HqdDkKovN1wKoxEQcrV4cQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Thu, Jul 9, 2015 at 5:20 AM, Nicolas Paris <niparisco(at)gmail(dot)com> wrote:

> Hello,
>
> I wonder how understanding pg_stat_all_indexes working
>
> When I run an explain, some index are not used, but
> pg_stat_all_indexes.idx_scan is incremented for those indexes.
>

When the planner considers using a merge join on a indexed column, it uses
an index to check the endpoints of the column (the min and the max) to make
sure it has the latest values to get the most accurate estimate. This
causes the usage counts to get incremented. Even when it doesn't end up
using the merge join.

> Does this mean idx_scan is incremented each time the planner check if an
> index could be use whenever it won't use it ?
>

Not in general, only in a few peculiar cases.

Cheers,

Jeff

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Nicolas Paris 2015-07-09 20:34:25 QUERY PLANNER - Indexe mono column VS composite Index
Previous Message Graeme B. Bell 2015-07-09 16:31:29 Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?