Re: Table Partitioning Advice Request - Mailing list pgsql-general

From Scott Marlowe
Subject Re: Table Partitioning Advice Request
Date
Msg-id dcc563d10912171541w159925ddrfa134152a72553c9@mail.gmail.com
Whole thread Raw
In response to Re: Table Partitioning Advice Request  (Vincenzo Romano <vincenzo.romano@notorand.it>)
Responses Re: Table Partitioning Advice Request  (Vincenzo Romano <vincenzo.romano@notorand.it>)
List pgsql-general
On Thu, Dec 17, 2009 at 8:29 AM, Vincenzo Romano
<vincenzo.romano@notorand.it> wrote:
> 2009/12/17 Sam Jas <samjas33@yahoo.com>
>>
>> Rule is not advisable, Trigger is the best solution.
>
> Does the trigger solution need the TABLE CHECK constraint?
> It looks to me it won't.

The table check constraint is used during selects to pick just the
child tables needed to deliver the data you are asking for, assuming
the key value is in the where clause.

The main reason to avoid rules is that they're much less efficient
than triggers.  We use partitioning at work for our stats db, and
partition by day, and we have about 2 years worth of stats data, so
our insert trigger has about 700 if / elseif / else conditions in it,
and the trigger is still very very fast.  I tried it with rules before
and it was way too slow.

Note that the absolute fastest way to insert to the right child table
is to do it from the application side, choosing the right child table
there.

We automated our trigger creation.  While the trigger is huge in terms
of number of lines, speed wise the creation of the new trigger each
night at midnight is measured in milliseconds

pgsql-general by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Installing PL/pgSQL by default
Next
From: Antonio Goméz Soto
Date:
Subject: Re: alter table performance