To: Carlos Benkendorf <carlosbenkendorf@yahoo.com.br>
Cc: pgsql-performance@postgresql.org
Subject: Re: Is the optimizer choice right?
References: <20051219202258.30740.qmail@web35510.mail.mud.yahoo.com>
In-Reply-To: <20051219202258.30740.qmail@web35510.mail.mud.yahoo.com>
From: Greg Stark <gsstark@mit.edu>
Organization: The Emacs Conspiracy; member since 1992
Date: 19 Dec 2005 15:54:29 -0500
Message-ID: <87r788ajui.fsf@stark.xeocode.com>
Lines: 29
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit


Carlos Benkendorf <carlosbenkendorf@yahoo.com.br> writes:

> Hi,
>    
>   We´re running 8.03 and I´m trying to understand why the following SELECT doesn´t use iarchave05 index.
>    
>   If you disable seqscan then iarchave05 index is used and the total runtime
>   is about 50% less than when iarchave05 index is not used.
>    
>   Why is the optimizer not using iarchave05 index?

The optimizer is calculating that the index scan would require more i/o than
the sequential scan and be slower. The only reason it isn't is because most of
the data is cached from your previous tests.

If this test accurately represents the production situation and most of this
data is in fact routinely cached then you might consider lowering the
random_page_cost to represent this. The value of 4 is reasonable for actual
i/o but if most of the data is cached then you effectively are getting
something closer to 1. Try 2 or 1.5 or so.

Note that the sequential scan has to scan the entire table. The index scan has
to scan the entire table *and* the entire index, and in a pretty random order.
If the table didn't fit entirely in RAM it would end up reading the entire
table several times over.

-- 
greg