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
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 |