On Thu, May 14, 2020 at 12:39 AM Robert Haas <robertmh...@gmail.com> wrote: > > On Tue, May 12, 2020 at 1:01 AM Amit Kapila <amit.kapil...@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
