Re: Parallel INSERT (INTO ... SELECT ...)
От | Greg Nancarrow |
---|---|
Тема | Re: Parallel INSERT (INTO ... SELECT ...) |
Дата | |
Msg-id | CAJcOf-d6reDddDsO_0LcGixN1gCJhMnMYOaFY-oFqZfhn6EMDA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Parallel INSERT (INTO ... SELECT ...) (Amit Langote <amitlangote09@gmail.com>) |
Ответы |
Re: Parallel INSERT (INTO ... SELECT ...)
|
Список | pgsql-hackers |
On Thu, Feb 18, 2021 at 4:35 PM Amit Langote <amitlangote09@gmail.com> wrote: > > Looking at this again, I am a bit concerned about going over the whole > partition tree *twice* when making a parallel plan for insert into > partitioned tables. Maybe we should do what you did in your first > attempt a slightly differently -- add partition OIDs during the > max_parallel_hazard() initiated scan of the partition tree as you did. > Instead of adding them directly to PlannerGlobal.relationOids, add to, > say, PlannerInfo.targetPartitionOids and have set_plan_references() do > list_concat(glob->relationOids, list_copy(root->targetPartitionOids) > in the same place as setrefs-v3 does > add_target_partition_oids_recurse(). Thoughts? > Agreed, that might be a better approach, and that way we're also only recording the partition OIDs that the parallel-safety checks are relying on. I'll give it a go and see if I can detect any issues with this method. Regards, Greg Nancarrow Fujitsu Australia
В списке pgsql-hackers по дате отправления: