From: | Scott Ribe <scott_ribe(at)elevated-dev(dot)com> |
---|---|
To: | Rui DeSousa <rui(at)crazybean(dot)net> |
Cc: | Pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: update behavior |
Date: | 2025-06-19 17:58:36 |
Message-ID: | 54495544-60AB-4CC8-9F47-78B33F4D99C4@elevated-dev.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
> On Jun 19, 2025, at 11:54 AM, Rui DeSousa <rui(at)crazybean(dot)net> wrote:
>
>
>
>> On Jun 19, 2025, at 1:23 PM, Scott Ribe <scott_ribe(at)elevated-dev(dot)com> wrote:
>>
>> I believe that if I UPDATE a row with the same values that it already has, this still dirties pages, writes the row, generates a WAL entry. There is no shortcut in the processing that's "hey, there's not really a change here, we'll just leave storage alone".
>>
>> Is this correct?
>>
>
> Correct, but it can be avoided.
>
> No update occurs in this case:.
>
> update foo
> set data = ‘hello world’
> where id = 33
> and data is distinct from ‘hello world’
> ;
That was my thought when I posted the original question, when I didn't know about suppress_redundant_updates_trigger. Now I'm thinking the trigger is an option.
- The trigger has the advantage that one doesn't have to maintain the WHERE clause--especially if the list of columns is long.
- It has the disadvantage of always running, even in contexts where it might not be needed.
From | Date | Subject | |
---|---|---|---|
Next Message | Ron Johnson | 2025-06-19 18:06:08 | Re: update behavior |
Previous Message | Rui DeSousa | 2025-06-19 17:57:20 | Re: update behavior |