Hannes Erven <hannes@xxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
