Re: Deprecating RULES - Mailing list pgsql-hackers

On Wed, Oct 17, 2012 at 12:43 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
>
> On 10/17/2012 03:06 PM, Daniel Farina wrote:
>>
>> On Wed, Oct 17, 2012 at 10:50 AM, Andrew Dunstan <andrew@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.

I'll have to register my disagreement then, in the special case where
a feature becomes so obscure that many people don't have a wide-spread
intuition at what it's good at or used for.  Tom also said "build the
replacement," and without itemization of use cases, I don't even know
what that would look like -- perhaps such knowledge is assumed, but I
think it's assumed wrongly, so perhaps there just needs to be some
education.  At best you could define what to build somewhat
tautologically from the mechanism used by RULES, and that's not a very
good way to go about it, methinks.

Thank you for humoring me and fleshing out your case anyway.

> 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.

That's a good one.  So, would a more legitimate partitioning becoming
a feature be enough to assuage user-visible rules support?  Or are
there other cases?

> 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.

The bar for quality is also high.  Like I said: to my needs, one less
bug outweighs the advantages of rules, especially if that advantage is
carried over multiple years.  I still lose quite a bit in the
deprecation regardless: if even 0.1% of the customer base uses rules,
a sudden deprecation will cause us a lot of pain.  However, a slow
deprecation is a lot more manageable and, if it pays off in one more
bug solved a year or a better positioned feature maintained with
equivalent effort it will have been worth it.

That's another thing that has not come up for discussion: those who
maintain rules -- are they happy to do it? What is the investment of
time like?  I have been presuming a cost of maintenance, but I have
never heard someone who actually maintains rules regularly or
implements features that become more complex because of it try to size
the benefit one way or another.

-- 
fdr