Re: [HACKERS] Proposal : Parallel Merge Join

Поиск
Список
Период
Сортировка
От Dilip Kumar
Тема Re: [HACKERS] Proposal : Parallel Merge Join
Дата
Msg-id CAFiTN-thtfge7YOUz-gekbg90snJJFpr8TAdkJd9fE0rR03_0A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Proposal : Parallel Merge Join  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: [HACKERS] Proposal : Parallel Merge Join  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
On Fri, Feb 24, 2017 at 3:04 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:

Thanks for the comments.

> What advantage do you see for considering such a path when the cost of
> innerpath is more than cheapest_total_inner?  Remember the more paths
> we try to consider, the more time we spend in the planner.  By any
> chance are you able to generate any query where it will give benefit
> by considering costlier innerpath?

If inner_cheapest_total path is not parallel safe then I am trying to
find the cheapest parallel safe path and generate partial merge join.
I agree that it will consider one extra path while considering every
partial merge join path (I think with this addition we will not get
parallel merge path for the any more TPCH query).  I feel in general
we can get some better plan by this especially when gather is the
cheapest path for inner relation(which is not parallel safe) but at
the cost of considering some extra paths.  What is your thought on
this?


-- 
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)
Следующее
От: Dave Page
Дата:
Сообщение: [HACKERS] Monitoring roles patch