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 1uSK16-006And-AD for pgsql-admin@arkaria.postgresql.org; Thu, 19 Jun 2025 18:29:40 +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 1uSK12-00DrnN-1D for pgsql-admin@arkaria.postgresql.org; Thu, 19 Jun 2025 18:29:36 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uSK11-00DrnF-MD for pgsql-admin@lists.postgresql.org; Thu, 19 Jun 2025 18:29:36 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1uSK0z-002zbt-2g for pgsql-admin@lists.postgresql.org; Thu, 19 Jun 2025 18:29:35 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 55JITTim1483329; Thu, 19 Jun 2025 14:29:30 -0400 From: Tom Lane To: Scott Ribe cc: "David G. Johnston" , Pgsql-admin Subject: Re: update behavior In-reply-to: <58598CFA-7C0F-4629-9D54-C366CEC8CCB4@elevated-dev.com> References: <75F792AF-58DF-4559-A2E8-C89060D1E94E@elevated-dev.com> <0D31EA2C-9038-4C2D-A4CD-E602809F16CC@elevated-dev.com> <58598CFA-7C0F-4629-9D54-C366CEC8CCB4@elevated-dev.com> Comments: In-reply-to Scott Ribe message dated "Thu, 19 Jun 2025 11:48:30 -0600" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <1483327.1750357769.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Jun 2025 14:29:29 -0400 Message-ID: <1483328.1750357769@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Scott Ribe writes: > On Jun 19, 2025, at 11:39=E2=80=AFAM, Scott Ribe wrote: >> Wait, should suppress_redundant_updates_trigger be used even in this ca= se? Would it suppress the update before the constraint checks and invocati= on of the ON CONFLICT clause??? > Or no, duh, this starts with an INSERT where that won't be run, there is= no UPDATE until after the constraint violation, but then at that point it= would suppress the update? I believe we fire ON UPDATE triggers when an INSERT ON CONFLICT takes an UPDATE action, so it should do what you want. The overhead tradeoff is yours to make. regards, tom lane