Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uSJeb-0066eg-Bu for pgsql-admin@arkaria.postgresql.org; Thu, 19 Jun 2025 18:06:25 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1uSJeZ-00DiF8-Dw for pgsql-admin@arkaria.postgresql.org; Thu, 19 Jun 2025 18:06:24 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uSJeY-00DiEz-Uu for pgsql-admin@lists.postgresql.org; Thu, 19 Jun 2025 18:06:23 +0000 Received: from mail-oa1-x2b.google.com ([2001:4860:4864:20::2b]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uSJeX-002vrs-2T for pgsql-admin@lists.postgresql.org; Thu, 19 Jun 2025 18:06:22 +0000 Received: by mail-oa1-x2b.google.com with SMTP id 586e51a60fabf-2d4e91512b4so634837fac.1 for ; Thu, 19 Jun 2025 11:06:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1750356380; x=1750961180; darn=lists.postgresql.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=/hmQBxL7LaUsD2mgR61ZwgksZDpYG+l7D3dzOjhwDgc=; b=ap30bcQJbL7ex3ANjXRcZzRPxMqfVzqN7fqASlWKpZo/0RHxhfBl5zBP84t9qxUSen A0IKDvc9IEJZmw9idzUE2abarWgeCdATkx4o+NQsMn+g+8oReH86WQ5dMCaiD8jzZXEA buyiQUdfVkXW7laqKi7WhnyAt1rcaK0uMFsyWOzQZY/iVTFDlZpHXWMyhtPgEu2NY7lL HaoLjlzc5fEnrgPFNzr5qzAmguec30rlge1slcGNdkgUOlmF9TLlHwzWpCxVUYEkuWga fUzgBFU9dYq+DAf9g7ZS7cK1cXwIbY/akzqGJnwxz8pvtJV/Z2sqylHZ6vUxkWoNsTSx zFLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750356380; x=1750961180; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=/hmQBxL7LaUsD2mgR61ZwgksZDpYG+l7D3dzOjhwDgc=; b=vB+PBxxqyFAp6Caq1SsXgPoQhZupBOAJEVtksBvcn3dUn+5/izK9sOiSNMLDydhX60 ByDg9RFZpy9lAQIwrTdNcP+uHJpvsE8hYKcalcwtwDnZIJ2zlWJ/uJAv5S1VcAlIx+xT UuG47ulQ/+smLUx9YcTZptZqpLfLPlQGY0FKRfNSfFMk7NxZ57wxIR34QKuEIMITQgJh tK1x11wb6FpPjnRF5bKnRUzOXoF9sRQt8O3KkbBX+CFskD+qYttSKi+ZwJfNMsP+j3O4 lVutgyXVdXRkGZCORLuNGvW7PqNo09lBz5xLexOG3FQM+sLSdSEOoNRGY5YxQiY9RFcQ u2wg== X-Gm-Message-State: AOJu0YwRERaKv8fOgy7L2c+9QwLGrqrhlom9O4UImx+SyTk3nBHct14F XafIHBznKvp+K62Er/B3ECPG+V+AAKKMlBo41SzqC18d1UxKh+ClXCFbJepqW4fNs3s0XGHreTM 3HVng7rBe5INRemts/77Zvtw4UxOhA9RWRQ== X-Gm-Gg: ASbGncu1hAVslIgKuIivBviqfbX2d6N4sKenlX9hj9a6YM9A/JKqoDwMO7EoK7UpykB Uy6AW8x1QTn7u92n8570PzkIiK0NP9OtoaEYl1ge5Vv1+7cfFRAjb3KLKE/4b9ocfCKred/AgAs jT7oS4PFDS0Q59hP0M9vBcOETSiMfartmw2gU6jM5awtMq X-Google-Smtp-Source: AGHT+IE5Sgyw5h7tcBC3SNrnBRj1ETgrMl/w98RvyotYohvilMWXbhe0UiQiZj2t7sC0YCLRJa4XGYGobTnxT89FDxw= X-Received: by 2002:a05:6871:720:b0:2e9:7e3:933f with SMTP id 586e51a60fabf-2eeee39e877mr60036fac.3.1750356379664; Thu, 19 Jun 2025 11:06:19 -0700 (PDT) MIME-Version: 1.0 References: <75F792AF-58DF-4559-A2E8-C89060D1E94E@elevated-dev.com> <4CE055A7-2368-4FD2-A900-52BFE4732641@crazybean.net> <54495544-60AB-4CC8-9F47-78B33F4D99C4@elevated-dev.com> In-Reply-To: <54495544-60AB-4CC8-9F47-78B33F4D99C4@elevated-dev.com> From: Ron Johnson Date: Thu, 19 Jun 2025 14:06:08 -0400 X-Gm-Features: Ac12FXyV2DST94ZhAauKAm399oOVX75AVCKzP2hey34vgG3LrruTXn4VlRq0z3I Message-ID: Subject: Re: update behavior To: Pgsql-admin Content-Type: multipart/alternative; boundary="0000000000003d86900637f09a8a" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000003d86900637f09a8a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jun 19, 2025 at 1:59=E2=80=AFPM Scott Ribe wrote: > > On Jun 19, 2025, at 11:54=E2=80=AFAM, Rui DeSousa w= rote: > > > > > > > >> On Jun 19, 2025, at 1:23 PM, Scott Ribe > 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. The= re > 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 =3D =E2=80=98hello world=E2=80=99 > > where id =3D 33 > > and data is distinct from =E2=80=98hello world=E2=80=99 > > ; > > 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 trigg= er > 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=3D50 (so as to enable HOT updates) mitigate the problem? --=20 Death to , and butter sauce. Don't boil me, I'm still alive. lobster! --0000000000003d86900637f09a8a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jun 19, 2025 at 1:59=E2=80=AFPM S= cott Ribe <scott_ribe@ele= vated-dev.com> wrote:
> On Jun 19, 2= 025, at 11:54=E2=80=AFAM, Rui DeSousa <rui@crazybean.net> wrote:
>
>
>
>> On Jun 19, 2025, at 1:23 PM, Scott Ribe <scott_ribe@elevated-dev.com&= gt; wrote:
>>
>> I believe that if I UPDATE a row with the same values that it alre= ady has, this still dirties pages, writes the row, generates a WAL entry. T= here 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
>=C2=A0 =C2=A0set data =3D =E2=80=98hello world=E2=80=99
> where id =3D 33
>=C2=A0 =C2=A0 and data is distinct from =E2=80=98hello world=E2=80=99 > ;

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 tri= gger is an option.

- The trigger has the advantage that one doesn't have to maintain the W= HERE clause--especially if the list of columns is long.
- It has the disadvantage of always running, even in contexts where it migh= t not be needed.
=C2=A0
How much would fillf= actor=3D50 (so as to enable HOT updates) mitigate the problem?
<= div>
--
Death to <Redacted&g= t;, and butter sauce.
Don't boil me, I'm still alive.
<= div><Redacted> lobster!
--0000000000003d86900637f09a8a--