On Thu, May 14, 2020 at 12:39 AM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Tue, May 12, 2020 at 1:01 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > I don't understand why we need to do something special for combo CIDs
> > if they are not generated during this operation?
>
> Hmm. Well I guess if they're not being generated then we don't need to
> do anything about them, but I still think we should try to work around
> having to disable parallelism for a table which is referenced by
> foreign keys.
>
Okay, just to be clear, we want to allow parallelism for a table that
has foreign keys. Basically, a parallel copy should work while
loading data into tables having FK references.
To support that, we need to consider a few things.
a. Currently, we increment the command counter each time we take a key
share lock on a tuple during trigger execution. I am really not sure
if this is required during Copy command execution or we can just
increment it once for the copy. If we need to increment the command
counter just once for copy command then for the parallel copy we can
ensure that we do it just once at the end of the parallel copy but if
not then we might need some special handling.
b. Another point is that after inserting rows we record CTIDs of the
tuples in the event queue and then once all tuples are processed we
call FK trigger for each CTID. Now, with parallelism, the FK checks
will be processed once the worker processed one chunk. I don't see
any problem with it but still, this will be a bit different from what
we do in serial case. Do you see any problem with this?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
