Date: Thu, 18 May 2006 21:48:13 +0200
From: "Steinar H. Gunderson" <sgunderson@bigfoot.com>
To: pgsql-performance@postgresql.org
Subject: Re: why is bitmap index chosen for this query?
Message-ID: <20060518194813.GA8539@uio.no>
Mail-Followup-To: pgsql-performance@postgresql.org
References: <16019.1147973659@sss.pgh.pa.us>
	<20060518193818.81332.qmail@web30710.mail.mud.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20060518193818.81332.qmail@web30710.mail.mud.yahoo.com>
User-Agent: Mutt/1.5.11+cvs20060403

On Thu, May 18, 2006 at 12:38:18PM -0700, Stephen Byers wrote:
> I repeated explain analyze on the query 5 times and it came up with the same plan.

Yes, but did it end up with the same runtime? That's the interesting part --
the plan will almost always be identical between explain analyze runs given
that you haven't done anything in between them.

> You asked about index order and physical table order.  In general the index
> order is indeed close to the same order as the physical table order.
> However, this query is likely an exception.  The data is actually from a
> backup server that has filled a hole for some of the time range that I'm
> specifying in my query.

Well, it still isn't all that far-fetched to believe that the data has lots
of correlation (which helps the index scan quite a lot) that the planner
isn't able to pick up. I don't know the details here, so I can't tell you how
the correlation for such a query (WHERE a=foo and b between bar and baz) is
estimated. Something tells me someone else might, though. :-)

/* Steinar */
-- 
Homepage: http://www.sesse.net/