Re: [HACKERS] why not parallel seq scan for slow functions
От | Amit Kapila |
---|---|
Тема | Re: [HACKERS] why not parallel seq scan for slow functions |
Дата | |
Msg-id | CAA4eK1LCWeWKVb=8iWS+=6idoXguhnu4_9_z4u_supEvF_ao0w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] why not parallel seq scan for slow functions (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [HACKERS] why not parallel seq scan for slow functions
|
Список | pgsql-hackers |
On Tue, Jan 30, 2018 at 3:30 AM, Robert Haas <robertmhaas@gmail.com> wrote: > On Sun, Jan 28, 2018 at 10:13 PM, Amit Kapila <amit.kapila16@gmail.com> wrote: >> If we want to get rid of Gather (Merge) checks in >> apply_projection_to_path(), then we need some way to add a projection >> path to the subpath of gather node even if that is capable of >> projection as we do now. I think changing the order of applying >> scan/join target won't address that unless we decide to do it for >> every partial path. Another way could be that we handle that in >> generate_gather_paths, but I think that won't be the idle place to add >> projection. >> >> If we want, we can compute the parallel-safety of scan/join target >> once in grouping_planner and then pass it in apply_projection_to_path >> to address your main concern. > > I spent some time today hacking on this; see attached. It needs more > work, but you can see what I have in mind. > I can see what you have in mind, but I think we still need to change the parallel safety flag of the path if *_target is not parallel safe either inside apply_projection_to_path or may be outside where it is called. Basically, I am talking about below code: @@ -2473,57 +2469,6 @@ apply_projection_to_path(PlannerInfo *root, { .. - else if (path->parallel_safe && - !is_parallel_safe(root, (Node *) target->exprs)) - { - /* - * We're inserting a parallel-restricted target list into a path - * currently marked parallel-safe, so we have to mark it as no longer - * safe. - */ - path->parallel_safe = false; - } - .. } I can take care of dealing with this unless you think otherwise. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: