2009/12/18 Scott Marlowe :
> 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
On Thu, Dec 17, 2009 at 8:29 AM, Vincenzo Romano
wrote:
> 2009/12/17 Sam Jas
>>
>> 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
chi
2009/12/17 Dimitri Fontaine :
> Vincenzo Romano writes:
>> Is there any performance study for the trigger-based implementation?
>
> Consider that if you use RULE to partition, when you DROP a partition
> the INSERTs are locked out because the query depends on the table being
> droped.
>
> That alo
Vincenzo Romano writes:
> Is there any performance study for the trigger-based implementation?
Consider that if you use RULE to partition, when you DROP a partition
the INSERTs are locked out because the query depends on the table being
droped.
That alone could lead you to stop considering RULEs
2009/12/17 Sam Jas
>
> 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.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/m
2009/12/17 David Fetter :
>> You really think that calling and running a trigger function for every
>> line is the best solution?
>
> Yes. The trigger function is choosing from a small subset of the
> tables, or you know which tables exactly the rows are going into and
> insert them there.
So I u
On Thu, Dec 17, 2009 at 02:41:40PM +0100, Vincenzo Romano wrote:
> > 2009/12/17 Sam Jas
> > Rule is not advisable, Trigger is the best solution.
> If you have to choose among a couple hundred partition tables, the
> trigger function body is far from trivial!
It's possible to generate such code a
lution.
>
> ---
> Thanks
> Sam Jas
>
> --- On Thu, 17/12/09, Vincenzo Romano wrote:
>
> From: Vincenzo Romano
> Subject: [GENERAL] Table Partitioning Advice Request
> To: pgsql-general@postgresql.org
> Date: Thursday, 17 December, 2009, 11:05 AM
>
> Hi all.
>
&
Rule is not advisable, Trigger is the best solution.
---
Thanks
Sam Jas
--- On Thu, 17/12/09, Vincenzo Romano wrote:
From: Vincenzo Romano
Subject: [GENERAL] Table Partitioning Advice Request
To: pgsql-general@postgresql.org
Date: Thursday, 17 December, 2009, 11:05 AM
Hi all.
I'm pla
Hi all.
I'm planning to implement table partitioning as "suggested" (among
other sources) in the official documentation.
I'm using v8.4.2 at the moment.
My case is far from the general one as:
1. I'll never UPDATE or DELETE rows from partitioned tables (only INSERTs)
2. Rows will be inserted one-
10 matches
Mail list logo
