Re: minimal update

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.

cheers

andrew