Skip site navigation (1) Skip section navigation (2)

Re: table partioning performance

From: "Jim C(dot) Nasby" <jim(at)nasby(dot)net>
To: Steven Flatt <steven(dot)flatt(at)gmail(dot)com>
Cc: Colin Taylor <colin(dot)taylor(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: table partioning performance
Date: 2007-01-11 01:23:55
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-performance
On Wed, Jan 10, 2007 at 04:39:06PM -0500, Steven Flatt wrote:
> On 1/10/07, Jim C. Nasby <jim(at)nasby(dot)net> wrote:
> >
> >Except for the simplest partitioning cases, you'll be much better off
> >using a trigger on the parent table to direct inserts/updates/deletes to
> >the children. As a bonus, using a trigger makes it a lot more realistic
> >to deal with an update moving data between partitions.
> In our application, data is never moved between partitions.
> The problem I found with triggers is the non-robustness of the PLpgSQL
> record data type.  For example, in an "on insert" trigger, I can't determine
> the fields of the NEW record unless I hard code the column names into the
> trigger.  This makes it hard to write a generic trigger, which I can use for
> all our partitioned tables.  It would have been somewhat of a pain to write
> a separate trigger for each of our partitioned tables.
> For that and other reasons, we moved some of the insert logic up to the
> application level in our product.

Yeah, I think the key there would be to produce a function that wrote
the function for you.
Jim Nasby                                            jim(at)nasby(dot)net
EnterpriseDB      512.569.9461 (cell)

In response to

pgsql-performance by date

Next:From: Jim C. NasbyDate: 2007-01-11 01:27:09
Subject: Re: High inserts, bulk deletes - autovacuum vs scheduled vacuum
Previous:From: andrewDate: 2007-01-11 00:49:33

pgsql-hackers by date

Next:From: Richard TroyDate: 2007-01-11 01:35:41
Subject: Re: ideas for auto-processing patches
Previous:From: Gavin SherryDate: 2007-01-11 01:03:18
Subject: Re: ideas for auto-processing patches

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group