From: | Greg Smith <greg(at)2ndQuadrant(dot)com> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: seq scan in the case of max() on the primary key column |
Date: | 2011-06-17 18:00:00 |
Message-ID: | 4DFB9620.8030702@2ndQuadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 06/17/2011 08:43 AM, Shaun Thomas wrote:
> It's a bit of a hack, but it's worked fine for us while we wait for
> the planner to catch up. :)
Right. In situations where people can modify their application to
redirect MIN/MAX() calls over to directly query the individual
partitions, that's a great workaround. Your function is the slickest
such solution I've seen for that, so filing it away in case this pops up
in that situation.
But if you can't touch the application code and just need it to work as
desired, you either need to use PostgreSQL 9.1 (not yet released) or
figure out how to backport that fix into an earlier version (not easy).
A babbled a bit about this specific case at
http://blog.2ndquadrant.com/en/2011/06/max-partitioning-with-min-pain.html
if anyone wants more information, or a specific simple test case to play
with.
--
Greg Smith 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2011-06-17 20:31:17 | Re: seq scan in the case of max() on the primary key column |
Previous Message | Greg Smith | 2011-06-17 17:54:10 | Re: Degrading PostgreSQL 8.4 write performance |