Re: Parallel INSERT (INTO ... SELECT ...)
От | Greg Nancarrow |
---|---|
Тема | Re: Parallel INSERT (INTO ... SELECT ...) |
Дата | |
Msg-id | CAJcOf-fg-Xit7M=Fz9d6wLRVR4MJF=Nnd1cAxhyaNrByzEAPhA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Parallel INSERT (INTO ... SELECT ...) (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>) |
Ответы |
Re: Parallel INSERT (INTO ... SELECT ...)
|
Список | pgsql-hackers |
On Tue, Oct 6, 2020 at 9:10 PM Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> wrote: > But the problem may arise if a partitioned table has foreign table as > a partition, I think we can not allow parallelism for this case too, > but it's hard to determine ahead of time whether a table has a foreign > partition.(See [1] in copy.c) > Thanks, I had seen that as a potential issue when scanning the code, but had forgotten to note it. I'll check your code again. > > > > - Added support for before/after statement-level INSERT triggers > > (can't allow parallel workers to execute these) > > > > I think we can allow parallelism for before statement level-triggers. > Leader can execute this trigger and go for parallel inserts. > My attached patch implements the before/after statement-level trigger invocation. (For INSERT INTO ... SELECT... case, it needs to account for parallel and non-parallel INSERT, and also the fact that, as the patch currently stands, the leader also participates in a parallel INSERT - so I found it necessary to invoke those triggers at the Gather node level in that case). > How about before row, after row, instead row, new table type triggers? > My attached patch does not allow parallel INSERT if there are any row-level triggers (as the trigger functions could see a different and unpredictable table state compared to non-parallel INSERT, even if otherwise parallel-safe). Regards, Greg Nancarrow Fujitsu Australia
В списке pgsql-hackers по дате отправления: