From: | Ken Geis <kgeis(at)speakeasy(dot)org> |
---|---|
To: | Bruno Wolff III <bruno(at)wolff(dot)to> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: bad estimates |
Date: | 2003-08-29 04:09:00 |
Message-ID: | 3F4ED1DC.50808@speakeasy.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Bruno Wolff III wrote:
> On Thu, Aug 28, 2003 at 20:46:00 -0700,
> Ken Geis <kgeis(at)speakeasy(dot)org> wrote:
>>It is not the table or the query that is wrong. It is either the db
>>parameters or the optimizer itself.
...
>
> It is still odd that you didn't get a big speed up for just the min though.
> You example did have the stock id and the date as the primary key which
> would make sense since the stock id and stock price on a day wouldn't
> be guarenteed to be unique. Are you absolutely sure you have a combined
> key on the stock id and the stock price?
I am positive! I can send a log if you want, but I won't post it to the
list.
The arity on the data is roughly 1500 price_dates per stock_id.
I was able to get the query to return in a reasonable amount of time
(still ~3 minutes) by forcing a nested loop path using SQL functions
instead of min and max.
I'm going to run comparisons on 7.3.3 and 7.4-beta2. I'll also look
into the optimizer source to try to figure out why it thinks scanning
this index is so expensive.
Ken
From | Date | Subject | |
---|---|---|---|
Next Message | scott.marlowe | 2003-08-29 04:22:35 | Re: opinion on RAID choice |
Previous Message | Bruno Wolff III | 2003-08-29 04:05:19 | Re: bad estimates |