[Greg Smith] > Here's the comment from that describing the main technique used to fix it: > > "This module tries to replace MIN/MAX aggregate functions by subqueries of > the form > > (SELECT col FROM tab WHERE ... ORDER BY col ASC/DESC LIMIT 1) Huh ... that sounds a bit like pg 8.0 to me ;-) I remember on 7.x one had to write "select id from table order by id desc limit 1" to force through a quick index scan. This was fixed in 8.0 IIRC. I did test "select id from table order by id desc limit 1" on my parent table yesterday, it would still do the seq-scan. Even adding a where-restriction to make sure only one partition was queried I still got the seq-scan. > Unfortunately that change ends a series of 6 commits of optimizer > refactoring in this area, so it's not the case that you just apply this one > commit as a bug-fix to a 9.0 system. I have a project in process to do the > full backport needed I might be able to share with you if that works out, > and you're willing to run with a customer patched server process. In this particular case, "wait for 9.1" seems to be the best option :-) -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
