Re: seq scan in the case of max() on the primary key column

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

In response to

Browse pgsql-performance by date

  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