Message-ID: <4DFB9620.8030702@2ndQuadrant.com>
Date: Fri, 17 Jun 2011 14:00:00 -0400
From: Greg Smith <greg@2ndQuadrant.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20110505 Icedove/3.0.11
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: Re: seq scan in the case of max() on the primary key column
References: <BANLkTikntdSrhneCPzPutY9T-sAQpFXTMw@mail.gmail.com>
	<BANLkTikuFEyOse=sUoH0BXYrpUW=7Pp_tw@mail.gmail.com>
	<4DFA4D2F.8020101@peak6.com>
	<BANLkTikohJ71z=Q0XmEwME6YRD8ev33mwQ@mail.gmail.com>
	<4DFB4C02.3020505@peak6.com>
In-Reply-To: <4DFB4C02.3020505@peak6.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books