Re: [HACKERS] why not parallel seq scan for slow functions

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: [HACKERS] why not parallel seq scan for slow functions
Дата
Msg-id CAMkU=1zMC1PAjOeFYUifXWpYg4MUo_SrdjWcf-UVRcvKrsnUew@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] why not parallel seq scan for slow functions  (Dilip Kumar <dilipbalaut@gmail.com>)
Ответы Re: [HACKERS] why not parallel seq scan for slow functions  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
On Mon, Jul 10, 2017 at 9:51 PM, Dilip Kumar <dilipbalaut@gmail.com> wrote:


In below function, we always multiply the target->cost.per_tuple with
path->rows, but in case of gather it should multiply this with
subpath->rows

apply_projection_to_path()
....

path->startup_cost += target->cost.startup - oldcost.startup;
path->total_cost += target->cost.startup - oldcost.startup +
(target->cost.per_tuple - oldcost.per_tuple) * path->rows;


So because of this high projection cost the seqpath and parallel path
both have fuzzily same cost but seqpath is winning because it's
parallel safe.

I think you are correct.  However, unless parallel_tuple_cost is set very low, apply_projection_to_path never gets called with the Gather path as an argument.  It gets ruled out at some earlier stage, presumably because it assumes the projection step cannot make it win if it is already behind by enough.

So the attached patch improves things, but doesn't go far enough.

Cheers,

Jeff
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Dean Rasheed
Дата:
Сообщение: Re: [HACKERS] Multi column range partition table
Следующее
От: Mark Rofail
Дата:
Сообщение: Re: [HACKERS] GSoC 2017: Foreign Key Arrays