Date: Fri, 25 Nov 2005 09:32:00 -0300
From: Alvaro Herrera <alvherre@commandprompt.com>
To: pgsql-performance@postgresql.org
Subject: Re: 8.1 count(*) distinct: IndexScan/SeqScan
Message-ID: <20051125123200.GD14707@surnet.cl>
Mail-Followup-To: pgsql-performance@postgresql.org
References: <334D9941-B5B3-4D18-8312-F85D0FB054ED@rilk.com>
	<A6F55E12-4479-49F6-B3EE-8CFCC8541179@rilk.com>
	<17380.1132886273@sss.pgh.pa.us> <438681E0.6070006@kylecordes.com>
	<20051125114017.GA10575@uio.no>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20051125114017.GA10575@uio.no>
User-Agent: Mutt/1.5.11

Steinar H. Gunderson wrote:
> On Thu, Nov 24, 2005 at 09:15:44PM -0600, Kyle Cordes wrote:
> > I have hit cases where I have a query for which there is a somewhat 
> > "obvious" (to a human...) query plan that should make it possible to get 
> > a query answer pretty quickly.  Yet the query "never" finishes (or 
> > rather, after hours of waiting I finally kill it).  I assume this is 
> > because of a sub-optimal query plan.  But, it appears that an EXPLAIN 
> > ANALYZE runs the actual query, so it takes as long as the actual query.
> 
> In this case, you probably can't do better than EXPLAIN. Look at the
> estimates, find out if the cost is way high somewhere.

Also you want to make absolutely sure all the involved tables have been
ANALYZEd recently.

If you have weird cases where there is an obvious query plan and the
optimizer is not using it, by all means submit it so that developers can
take a look at how to improve the optimizer.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.