Hannes Erven <hannes@erven.at> writes:
> On 2013-03-22 13:32, Bertrand Janin wrote:
>>> UPDATE demo
>>> SET value = value
>>> WHERE id = 1;
> On 2013-03-22 14:55, Tom Lane wrote:
>> It's not *necessary* to do so. However, avoiding it would require
>> sitting there and comparing the old and new tuples,
> But in this case, no tuples would need to be compared: just by looking
> at the query is becomes clear that it is a no-op.
That's not clear at all; for example, there might be a BEFORE UPDATE
trigger that changes the row some more (perhaps by updating a timestamp
column, for instance). To avoid changing the behavior of triggers,
any optimization like this would have to be performed at a very low
level when the new tuple is just about to be written to disk.
Another factor in all this is that if you have an application that's in
the habit of issuing useless updates often enough for the situation to
be worth optimizing, it'd be far better to fix the application to not
issue such commands in the first place. No amount of short-circuiting
in the planner or executor can buy back the costs of transmitting and
parsing such queries.
regards, tom lane
