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 <[EMAIL PROTECTED]> http://www.jefftrout.com/ http://www.stuarthamm.net/ ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
