From: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
---|---|
To: | alvherre(at)2ndquadrant(dot)com |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: partitioned tables referenced by FKs |
Date: | 2018-11-05 21:53:19 |
Message-ID: | CADkLM=c+12dg8JdH7y2u0fitQM8oWCTQN4=mR_w7jXWqKvJdLg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>
>
> > 1. it seems that we will continue to to per-row RI checks for inserts and
> > updates. However, there already exists a bulk check in
> RI_Initial_Check().
> > Could we modify this bulk check to do RI checks on a per-statement basis
> > rather than a per-row basis?
>
> One of the goals when implementing trigger transition tables was to
> supplant the current per-row implementation of RI triggers with
> per-statement. I haven't done that, but AFAIK it remains possible :-)
>
> Changing that is definitely not a goal of this patch.
>
Then I may try to tackle it myself in a separate thread.
Without an implementation, I can't say, but if I had to guess, I would
> assume so. Or maybe there are clever optimizations for that particular
> case.
>
But in this case there is no actual defined trigger, it's internal code
making an SPI call...is there an indicator that tells us whether this
change was multi-row or not?
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2018-11-05 22:00:30 | Re: Why do pg_upgrade's test use the serial schedule? |
Previous Message | Dmitry Dolgov | 2018-11-05 21:51:39 | Re: [Bug Fix]ECPG: cancellation of significant digits on ECPG |