Re: minimal update

On Nov 8, 2007, at 10:46 , Andrew Dunstan wrote:

>
>
> Tom Lane wrote:
>> Michael Glaesemann <grzm@seespotcode.net> writes:
>>
>>> What would be the disadvantages of always doing this, i.e., just   
>>> making this part of the normal update path in the backend?
>>>
>>
>> (1) cycles wasted to no purpose in the vast majority of cases.
>>
>> (2) visibly inconsistent behavior for apps that pay attention
>> to ctid/xmin/etc.
>>
>> (3) visibly inconsistent behavior for apps that have AFTER triggers.
>>
>> There's enough other overhead in issuing an update (network,
>> parsing/planning/etc) that a sanely coded application should try
>> to avoid issuing no-op updates anyway.  The proposed trigger is
>> just a band-aid IMHO.
>>
>> I think having it as an optional trigger is a reasonable compromise.
>>
>>             
>>
>
> Right. I never proposed making this the default behaviour, for all  
> these good reasons.
>
> The point about making the app try to avoid no-op updates is that  
> this can impose some quite considerable code complexity on the app,  
> especially where the number of updated fields is large. It's  
> fragile and error-prone. A simple switch that can turn a trigger on  
> or off will be nicer. Syntax support for that might be even nicer,  
> but there appears to be some resistance to that, so I can easily  
> settle for the trigger.

This confirms what I thought. Thanks.

Michael Glaesemann
grzm seespotcode net