Date: Fri, 29 Aug 2003 09:36:13 -0700
From: Sean Chittenden <sean@chittenden.org>
To: Ken Geis <kgeis@speakeasy.org>
Cc: Bruno Wolff III <bruno@wolff.to>,
	pgsql-performance@postgresql.org
Subject: Re: bad estimates
Message-ID: <20030829163613.GA51475@perrin.nxad.com>
References: <3F4E99F7.7080604@speakeasy.org> <20030829025109.GD4373@wolff.to>
	<3F4EBF7E.8020602@speakeasy.org> <20030829030156.GF4373@wolff.to>
	<3F4EC1D0.5010503@speakeasy.org> <20030829033818.GA5577@wolff.to>
	<3F4ECC78.7090502@speakeasy.org>
	<20030829040519.GA5746@wolff.to> <3F4F7A07.30404@speakeasy.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3F4F7A07.30404@speakeasy.org>
User-Agent: Mutt/1.5.4i

> >If you want both the max and the min, then things are going to be a
> >bit more work. You are either going to want to do two separate
> >selects or join two selects or use subselects. If there aren't
> >enough prices per stock, the sequential scan might be fastest since
> >you only need to go through the table once and don't have to hit
> >the index blocks.
> >
> >It is still odd that you didn't get a big speed up for just the min though.
> 
> I found I'm suffering from an effect detailed in a previous thread titled
> 
> 	Does "correlation" mislead the optimizer on large tables?

I don't know about large tables, but this is a big problem and
something I'm going to spend some time validating later today.  I
think Manfred's patch is pretty good and certainly better than where
we are but I haven't used it yet to see if it's the magic ticket for
many of these index problems.

-sc

-- 
Sean Chittenden