Re: bad estimates

On Fri, 29 Aug 2003, Ken Geis wrote:

> Some good news here. Doing the same as above on 7.4beta2 took 29
> minutes. Now, the 7.3.3 was on reiser and 7.4 on ext2, so take that as
> you will. 7.4's index selectivity estimate seems much better; 7.3.3's
> anticipated rows was ten times the actual; 7.4's is one half of the actual.
>
Min() & Max() unfortunatly suck on PG. It will be that way for a while
perhaps at some point someone will make a "special" case and convince
-HACKERS it is a Good Thing(tm) (Like select count(*) from table being
'cached' - a lot of people probably get bad first impressions because of
that)

Would it be possible ot rewrite your queries replacing min/max with a
select stock_id from bigtable where blah = blorch order by stock_id
(desc|asc) limit 1? because that would enable PG to use an index and
magically "go fast". You may need a subselect..

--
Jeff Trout <jeff(at)jefftrout(dot)com>
http://www.jefftrout.com/
http://www.stuarthamm.net/