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

From: Shaun Thomas <sthomas(at)peak6(dot)com>
To: Svetlin Manavski <svetlin(dot)manavski(at)gmail(dot)com>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, <pgsql-performance(at)postgresql(dot)org>
Subject: Re: seq scan in the case of max() on the primary key column
Date: 2011-06-17 12:43:46
Message-ID: 4DFB4C02.3020505@peak6.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On 06/17/2011 06:22 AM, Svetlin Manavski wrote:

> Shaun, that solution is brilliant.

Don't thank me. I actually got the basic idea from a post here a couple
years ago. The only difference is I formalized it somewhat and put it in
our utility schema, where I put lots of other random useful stored procs
I've accumulated over the years. I have another one that works with
dates. :)

I assume you already modified it by removing the 'utility' schema prefix
from the recursive call. The recursive call is in case the child tables
are themselves used as a template for further inheritance. It's rare,
but possible. This function will always get you the max value on a
column in a series of partitioned tables, and quickly so long as it's
indexed.

It's a bit of a hack, but it's worked fine for us while we wait for the
planner to catch up. :)

--
Shaun Thomas
OptionsHouse | 141 W. Jackson Blvd. | Suite 800 | Chicago IL, 60604
312-676-8870
sthomas(at)peak6(dot)com

______________________________________________

See http://www.peak6.com/email_disclaimer.php
for terms and conditions related to this email

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Kabu Taah 2011-06-17 12:48:47 Degrading PostgreSQL 8.4 write performance
Previous Message Svetlin Manavski 2011-06-17 11:22:21 Re: seq scan in the case of max() on the primary key column