Re: [HACKERS] Proposal : Parallel Merge Join

Поиск
Список
Период
Сортировка
От Dilip Kumar
Тема Re: [HACKERS] Proposal : Parallel Merge Join
Дата
Msg-id CAFiTN-u2kzm6wUpr2A9F1Q3Ya9wN8xSReG9OY1OKoRqi1+jtww@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Proposal : Parallel Merge Join  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [HACKERS] Proposal : Parallel Merge Join  (Dilip Kumar <dilipbalaut@gmail.com>)
Список pgsql-hackers
On Tue, Dec 13, 2016 at 12:11 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>
> Hmm, so it seems my initial guess that we didn't need to bother
> generating such paths was wrong.  Oops.
>
> This patch is hard to read because it is reorganizing a bunch of code
> as well as adding new functionality.  Perhaps you could separate it
> into two patches, one with the refactoring and then the other with the
> new functionality.

Okay, I can do that.

>  Actually, though, I don't understand why you need
> so much rearrangement....

Actually match_unsorted_outer is quite complex function and
considering merge join path for many cases, And In my opinion those
all paths should be considered for partial outer as well.

So one option was to duplicate that part of code. But I chose to move
all that code from match_unsorted_outer (which is related to
generating various merge join path) to new function called
generate_mergejoin_path. And, use it for normal outer path as well as
for partial outer path.

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



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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] PATCH: recursive json_populate_record()
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] exposing wait events for non-backends (was: Trackingwait event for latches)