From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)net> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: UPDATE sql question |
Date: | 2003-08-01 16:15:45 |
Message-ID: | 14738.1059754545@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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 :-(. 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
From | Date | Subject | |
---|---|---|---|
Next Message | Ron Johnson | 2003-08-01 16:40:06 | Re: UPDATE sql question |
Previous Message | Ron Johnson | 2003-08-01 15:54:25 | Re: UPDATE sql question |