Re: UPDATE run check constraints for affected columns only - Mailing list pgsql-hackers

From jian he
Subject Re: UPDATE run check constraints for affected columns only
Date
Msg-id CACJufxGopPDQPntgivZjZ8-iq5SSZ1gd=eB1_7+o5qujOfy5RA@mail.gmail.com
Whole thread Raw
In response to Re: UPDATE run check constraints for affected columns only  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Dec 1, 2025 at 2:33 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> jian he <jian.universality@gmail.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

pgsql-hackers by date:

Previous
From: Akshat Jaimini
Date:
Subject: Re: Always show correct error message for statement timeouts, fixes random buildfarm failures
Next
From: "Jelte Fennema-Nio"
Date:
Subject: Re: Bump soft open file limit (RLIMIT_NOFILE) to hard limit on startup