| 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.
| Attachment | Content-Type | Size |
|---|---|---|
| v2-0001-UPDATE-run-check-constraints-for-affected-columns-only.patch | text/x-patch | 10.4 KB |
| 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 |