From: | Sean Chittenden <sean(at)chittenden(dot)org> |
---|---|
To: | Ken Geis <kgeis(at)speakeasy(dot)org> |
Cc: | Bruno Wolff III <bruno(at)wolff(dot)to>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: bad estimates |
Date: | 2003-08-29 16:36:13 |
Message-ID: | 20030829163613.GA51475@perrin.nxad.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
> >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
From | Date | Subject | |
---|---|---|---|
Next Message | Ken Geis | 2003-08-29 16:56:59 | Re: bad estimates |
Previous Message | William Yu | 2003-08-29 16:33:51 | Re: Hardware recommendations to scale to silly load |