Skip site navigation (1) Skip section navigation (2)

Re: bad estimates

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: (view raw, whole thread or download thread mbox)
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 

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.


In response to


pgsql-performance by date

Next:From: scott.marloweDate: 2003-08-29 04:22:35
Subject: Re: opinion on RAID choice
Previous:From: Bruno Wolff IIIDate: 2003-08-29 04:05:19
Subject: Re: bad estimates

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group