Re: UPDATE run check constraints for affected columns only

From: jian he <jian(dot)universality(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: UPDATE run check constraints for affected columns only
Date: 2025-12-07 15:50:37
Message-ID: CACJufxGopPDQPntgivZjZ8-iq5SSZ1gd=eB1_7+o5qujOfy5RA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Dec 1, 2025 at 2:33 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> jian he <jian(dot)universality(at)gmail(dot)com> writes:
> > The attached patch implements the $subject.
>
> Does this cover the case where a BEFORE UPDATE trigger has modified
> columns that were not mentioned in UPDATE...SET?
>
> regards, tom lane

hi.
in ExecInitGenerated, we have:

/*
* In an UPDATE, we can skip computing any generated columns that do not
* depend on any UPDATE target column. But if there is a BEFORE ROW
* UPDATE trigger, we cannot skip because the trigger might change more
* columns.
*/
if (cmdtype == CMD_UPDATE &&
!(rel->trigdesc && rel->trigdesc->trig_update_before_row))
updatedCols = ExecGetUpdatedCols(resultRelInfo, estate);
else
updatedCols = NULL;

So I applied the equivalent approach. This should works fine, because if we are
able to skip computing certain generated columns, then we sure sure be able to
skip evaluating some check constraints.

--
jian
https://www.enterprisedb.com

Attachment Content-Type Size
v2-0001-UPDATE-run-check-constraints-for-affected-columns-only.patch text/x-patch 10.4 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jelte Fennema-Nio 2025-12-07 15:55:17 Re: Bump soft open file limit (RLIMIT_NOFILE) to hard limit on startup
Previous Message Akshat Jaimini 2025-12-07 14:38:59 Re: Always show correct error message for statement timeouts, fixes random buildfarm failures