Re: UPDATE run check constraints for affected columns only

On Sat, Mar 7, 2026 at 12:10 AM Florin Irion <irionr@gmail.com> wrote:
>
> Hi Jian,
>
> An alternative that preserves the optimization for MERGE UPDATE actions
> would be to follow the existing ri_GeneratedExprsI/ri_GeneratedExprsU
> pattern — split into two separate cached arrays:
>
> ```
> /* array of expr states for checking check constraints */
> ExprState **ri_CheckConstraintExprsI; /* for INSERT */
> ExprState **ri_CheckConstraintExprsU; /* for UPDATE */
> ```

I have given it a try, please see attached v7.
I don’t have a strong preference for either v6 or v7.

> 2. The cross-partition update test comment says "cannot be skipped", but
> cross-partition UPDATE goes through ExecCrossPartitionUpdate which
> does DELETE + INSERT. The constraint check happens via ExecInsert with
> CMD_INSERT on the destination partition, so the optimization was never
> applicable. The test doesn't exercise anything specific to this patch.
>

OK. I kept these tests. I think covering this scenario is useful.  Perhaps it
has already been tested elsewhere, but including it here makes the tests more
complete



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