On 10/17/2012 03:06 PM, Daniel Farina wrote:
On Wed, Oct 17, 2012 at 10:50 AM, Andrew Dunstan <and...@dunslane.net> wrote:
Triggers necessarily operate on a row-at-a-time basis. In theory,
for at least some bulk operations, a rule could greatly outperform
a trigger. It's difficult to walk away from that - unless somebody
can prove that the advantage doesn't ever accrue in practice.
People can keep ignoring that if they like, but some of us won't. This
mantra of "there is no reason at all to use rules" is like climate change
denial - no matter how many times you say it that won't make it true.
I think there is an assumed presumption on behalf of those those
vigorously opposing the deprecation of rules that everyone understands
what the use cases for rules are and their respective commonality. So
far, the discussion has been pretty unenlightening to me, and I find
the notion that those in favor of deprecation are just skirting well
known questions ill justified. Just because an "in theory..." case
works better is not in and of itself enough to warrant a vigorous
defense -- perhaps I missed the email where people said "yes, I see
that all the time when rules are involved and wouldn't want to go
without it".
You and Josh seem to be strong proponents of rules for reasons other
than "I just don't want to break applications". That's not too many
to ask both of you: can you itemize your use cases and how important
you feel they are?
I'll cost-size it for you: for me, as of my current understanding, if
but one more defect can be removed per year by dropping all
maintenance of RULES in exchange, I'd take that trade, as I understand
things right now.
I'll give you one case, although I still think Tom is right - the onus
of proof is on those proposing to remove a feature, not the other way
around.
Some years ago I was partitioning a large data store. By far the fastest
way to do this, by about an order of magnitude, turned out to be using a
partitioning rule. In testing it was way faster than using a trigger,
even one written in C, or pulling out the individual partitions one by
one. And I don't thing writing triggers in C is an acceptable
replacement for rules anyway.
One I had the data partitioned I dropped the rule and put a trigger in
place.
Now I'd be fairly miffed if we just removed that capability. I
personally feel that the bar for removing features should be pretty darn
high.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
