Re: [HACKERS] why not parallel seq scan for slow functions
От | Amit Kapila |
---|---|
Тема | Re: [HACKERS] why not parallel seq scan for slow functions |
Дата | |
Msg-id | CAA4eK1+3uegH7Nf_9iMYfkRdzzJrE93_0SsA_bjsEySpnrj9xw@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, Aug 15, 2017 at 7:15 PM, Robert Haas <robertmhaas@gmail.com> wrote: > On Sat, Aug 12, 2017 at 9:18 AM, Amit Kapila <amit.kapila16@gmail.com> wrote: >> I think skipping a generation of gather paths for scan node or top >> level join node generated via standard_join_search seems straight >> forward, but skipping for paths generated via geqo seems to be tricky >> (See use of generate_gather_paths in merge_clump). Assuming, we find >> some way to skip it for top level scan/join node, I don't think that >> will be sufficient, we have some special way to push target list below >> Gather node in apply_projection_to_path, we need to move that part as >> well in generate_gather_paths. > > I don't think that can work, because at that point we don't know what > target list the upper node wants to impose. > I am suggesting to call generate_gather_paths just before we try to apply projection on paths in grouping_planner (file:planner.c; line:1787; commit:004a9702). Won't the target list for upper nodes be available at that point? -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: