Re: [HACKERS] why not parallel seq scan for slow functions
От | Dilip Kumar |
---|---|
Тема | Re: [HACKERS] why not parallel seq scan for slow functions |
Дата | |
Msg-id | CAFiTN-tsf9cwpnYVrFPnHJHgxaJp1oYxoFok4KOZu9-sXAU9zA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] why not parallel seq scan for slow functions (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: [HACKERS] why not parallel seq scan for slow functions
|
Список | pgsql-hackers |
On Sat, Aug 12, 2017 at 6:48 PM, Amit Kapila <amit.kapila16@gmail.com> wrote: > On Thu, Aug 10, 2017 at 1:07 AM, Robert Haas <robertmhaas@gmail.com> wrote: >> On Tue, Aug 8, 2017 at 3:50 AM, Amit Kapila <amit.kapila16@gmail.com> wrote: >>> Right. >>> > > 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). Either we can pass "num_gene" to merge_clump or we can store num_gene in the root. And inside merge_clump we can check. Do you see some more complexity? if (joinrel) { /* Create GatherPaths for any useful partial paths for rel */ if (old_clump->size + new_clump->size < num_gene) generate_gather_paths(root, joinrel); } 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. > -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: