On 06/22/2011 02:12 PM, Scott Marlowe wrote:
Given that many folks still run < 9.0 in production, the wiki page
should really have a version of that function for older versions,
whether it's long or not.
I updated the page already to be clear about what versions of PostgreSQL
it works on,
On 06/22/2011 01:12 PM, Scott Marlowe wrote:
Given that many folks still run< 9.0 in production, the wiki page
should really have a version of that function for older versions,
whether it's long or not.
This version does work on anything 8.3 and above. I just lamented on 9.0
because we decid
On Wed, Jun 22, 2011 at 7:12 AM, Shaun Thomas wrote:
> On 06/22/2011 04:55 AM, Marti Raudsepp wrote:
>
>> With Jim Nasby's idea to use regclass instead of relation names, the
>> function is now half its length and probably more reliable. There's no
>> need to touch pg_class directly at all.
>
> Sa
On 06/22/2011 05:55 AM, Marti Raudsepp wrote:
Now I created a wiki snippet page for this handy
feature here:
https://wiki.postgresql.org/wiki/Efficient_min/max_over_partitioned_table
I just tweaked this a bit to document the version compatibility issues
around it and make it easier to foll
On 06/22/2011 04:55 AM, Marti Raudsepp wrote:
With Jim Nasby's idea to use regclass instead of relation names, the
function is now half its length and probably more reliable. There's no
need to touch pg_class directly at all.
Sadly until we upgrade to EDB 9.0, I have to use my function. :) EDB
On Thu, Jun 16, 2011 at 21:36, Shaun Thomas wrote:
> You can call that instead of max, and it'll be much faster. You can create
> an analog for min if you need it. So for this, you'd call:
Cool, I've needed this function sometimes but never bothered enough to
write it myself. Now I created a wiki
On 06/17/2011 03:31 PM, Jim Nasby wrote:
c_parent_oid CONSTANT oid := (p_parent_schema || '.' ||
p_parent_table )::regclass;
Well isn't *that* a handy bit of magic. How did I not know about that?
Thanks!
--
Shaun Thomas
OptionsHouse | 141 W. Jackson Blvd. | Suite 800 | Chicago IL, 60604
312
On Jun 16, 2011, at 1:36 PM, Shaun Thomas wrote:
> /**
> * Return the Maximum INT Value for a Partitioned Table Column
> *
> * @param string Name of Schema of the base partition table.
> * @param string Name of the base partition table.
> * @param string Name of column to search.
> */
> CREATE O
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 gr
Yes, confirmed that the problem is in the partitioned table.
Shaun, that solution is brilliant.
Thank you,
Svetlin Manavski
On Thu, Jun 16, 2011 at 7:36 PM, Shaun Thomas wrote:
> On 06/16/2011 12:25 PM, Magnus Hagander wrote:
>
> PostgreSQL 9.0 is unable to use an index scan to find min/max on
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 stor
On 06/16/2011 12:25 PM, Magnus Hagander wrote:
PostgreSQL 9.0 is unable to use an index scan to find min/max on a
partitioned table. 9.1, however, can do that.
Unfortunately this is true. You can fake it this way though:
/**
* Return the Maximum INT Value for a Partitioned Table Column
*
* @p
On Thu, Jun 16, 2011 at 15:55, Svetlin Manavski
wrote:
> Hi everybody,
>
> I am running PostgreSQL 9.0 which performs well in most of the cases. I
> would skip all the parameters if these are not necessary.
> I need to frequently (every min) get the max value of the primary key column
> on some ta
On 2011-06-16 15:55, Svetlin Manavski wrote:
Hi everybody,
I am running PostgreSQL 9.0 which performs well in most of the cases. I
would skip all the parameters if these are not necessary.
I need to frequently (every min) get the max value of the primary key column
on some tables, like this cas
Hi everybody,
I am running PostgreSQL 9.0 which performs well in most of the cases. I
would skip all the parameters if these are not necessary.
I need to frequently (every min) get the max value of the primary key column
on some tables, like this case which works perfectly well:
explain analyze
15 matches
Mail list logo
