From: | Ron Johnson <ronljohnsonjr(at)gmail(dot)com> |
---|---|
To: | Pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org> |
Subject: | Re: update behavior |
Date: | 2025-06-19 18:06:08 |
Message-ID: | CANzqJaCj95JOKUd_ihcba4OqHTWnqEfz67hgaRezq4a49EF-eA@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On Thu, Jun 19, 2025 at 1:59 PM Scott Ribe <scott_ribe(at)elevated-dev(dot)com>
wrote:
> > 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.
>
How much would fillfactor=50 (so as to enable HOT updates) mitigate the
problem?
--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2025-06-19 18:29:29 | Re: update behavior |
Previous Message | Scott Ribe | 2025-06-19 17:58:36 | Re: update behavior |