Skip site navigation (1) Skip section navigation (2)

Re: An "obvious" index not being used

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Daniele Varrazzo <piro(at)develer(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: An "obvious" index not being used
Date: 2008-06-19 01:43:34
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
Daniele Varrazzo <piro(at)develer(dot)com> writes:
> There is an index in the field "foo.account_id" but is not used. The resulting 
> query plan is:

>   Aggregate  (cost=300940.70..300940.71 rows=1 width=0) (actual
> time=13412.088..13412.089 rows=1 loops=1)
>     ->  Hash IN Join  (cost=11.97..299858.32 rows=432953 width=0) (actual
> time=0.678..13307.074 rows=92790 loops=1)
>           Hash Cond: (foo.account_id =
>           ->  Seq Scan on foo  (cost=0.00..275591.14 rows=5313514 width=4)
> (actual time=0.014..7163.538 rows=5313514 loops=1)

Well, if the estimate of 432953 rows selected were correct, it'd be
right not to use the index.  Fetching one row in ten is not a chore
for an indexscan.  (I'm not sure it'd prefer an indexscan even with an
accurate 92K-row estimate, but at least you'd be in the realm where
tweaking random_page_cost would make a difference.)

I'm not sure why that estimate is so bad, given that you said you
increased the stats target on the table.  Is there anything particularly
skewed about the distribution of the account IDs?

			regards, tom lane

In response to


pgsql-performance by date

Next:From: Daniele VarrazzoDate: 2008-06-19 02:19:59
Subject: Re: An "obvious" index not being used
Previous:From: Daniele VarrazzoDate: 2008-06-19 01:07:11
Subject: An "obvious" index not being used

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group