Re: UPDATE sql question

From: Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)net>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: UPDATE sql question
Date: 2003-08-01 16:40:06
Message-ID: 1059756006.7508.643.camel@haggis
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Fri, 2003-08-01 at 11:15, Tom Lane wrote:
> Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)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 :-(.

Very true! How is it bad design to try and save an IO, though?

> Yeah,
> the comparisons might be cheap (or not, on some datatypes) ... but the
> potentially-avoided computation is reduced by a faster CPU as well.

But we don't know. MS, IBM or Oracle have the resources to do
that kind of analysis. We don't.

> 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.

Which is what I also said...
<QUOTE>
Of course, one could always say, "Hey, application! Don't update
unchanged values!!!!".
</QUOTE>

--
+-----------------------------------------------------------------+
| Ron Johnson, Jr. Home: ron(dot)l(dot)johnson(at)cox(dot)net |
| Jefferson, LA USA |
| |
| "I'm not a vegetarian because I love animals, I'm a vegetarian |
| because I hate vegetables!" |
| unknown |
+-----------------------------------------------------------------+

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Robert Partyka 2003-08-01 16:44:29 Re: How to do?
Previous Message Tom Lane 2003-08-01 16:15:45 Re: UPDATE sql question