Re: UPDATE sql question - Mailing list pgsql-general

From Tom Lane
Subject Re: UPDATE sql question
Date
Msg-id 14738.1059754545@sss.pgh.pa.us
Whole thread Raw
In response to Re: UPDATE sql question  (Ron Johnson <ron.l.johnson@cox.net>)
Responses Re: UPDATE sql question  (Ron Johnson <ron.l.johnson@cox.net>)
List pgsql-general
Ron Johnson <ron.l.johnson@cox.net> writes:
>> I'd think that in most cases, the extra time spent checking to see
>> whether the updated columns didn't change would be a net loss.

> Would it always be a net loss, though?

You're asking the wrong question.  From my perspective, the question
is whether it'd be a net win averaged across all UPDATEs at all
installations everywhere.  I can't believe that it would be.

> CPUs are so fast, nowadays.  How many microseconds *would* be spent?

That's been a standard excuse for bad design for decades now :-(.  Yeah,
the comparisons might be cheap (or not, on some datatypes) ... but the
potentially-avoided computation is reduced by a faster CPU as well.

If you have a particular application and table where no-op UPDATEs occur
often enough that it's really a win to suppress them, you can put in a
trigger to do it.  Or better, fix the application to not issue the
UPDATE in the first place; that saves way more computation for the same
basic comparison overhead.

            regards, tom lane

pgsql-general by date:

Previous
From: "scott.marlowe"
Date:
Subject: Re: Integrating the field auto-increment
Next
From: Ron Johnson
Date:
Subject: Re: UPDATE sql question