Re: [DOCS] Partition: use triggers instead of rules - Mailing list pgsql-patches

From Joshua D. Drake
Subject Re: [DOCS] Partition: use triggers instead of rules
Date
Msg-id 474EE992.2050209@commandprompt.com
Whole thread Raw
In response to Re: [DOCS] Partition: use triggers instead of rules  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [DOCS] Partition: use triggers instead of rules  (Bruce Momjian <bruce@momjian.us>)
Re: [DOCS] Partition: use triggers instead of rules  (Gregory Stark <stark@enterprisedb.com>)
Re: [DOCS] Partition: use triggers instead of rules  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [DOCS] Partition: use triggers instead of rules  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-patches
Tom Lane wrote:
> "Joshua D. Drake" <jd@commandprompt.com> writes:
>> Rules are extremely slow in comparisons and not anywhere near as
>> flexible. As I said up post yesterday... they work well in the basic
>> partitioning configuration but anything else they are extremely deficient.
>
> I think that the above claim is exceedingly narrow-minded.

We are talking about partitioning. It is supposed to be narrow-minded.

>  A trigger
> will probably beat a rule for inserts/updates involving a small number
> of rows.

Which is exactly what partitioning is doing.

  For large numbers of rows, like an INSERT/SELECT from another
> large table, the rule is likely to win, because its overhead is paid
> once per query not once per row.  Also, if you implement the trigger
> with an EXECUTE (forcing a planning cycle) intead of hard-coded
> commands, the speed advantage becomes even more dubious.

Not for partitioning. Although I agree with your sentiments for normal
operation.

Sincerely,

Joshua D. Drake



pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: [DOCS] Partition: use triggers instead of rules
Next
From: Bruce Momjian
Date:
Subject: Re: [DOCS] Partition: use triggers instead of rules