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
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? |