Re: Problem about postponing gathering partial paths for topmost scan/join rel

Поиск
Список
Период
Сортировка
От Richard Guo
Тема Re: Problem about postponing gathering partial paths for topmost scan/join rel
Дата
Msg-id CAMbWs4-HnzGqZkhGP8+QCWaSLq950w-AQsZ4t6nUta-iNAB+fA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Problem about postponing gathering partial paths for topmost scan/join rel  (Richard Guo <guofenglinux@gmail.com>)
Ответы Re: Problem about postponing gathering partial paths for topmost scan/join rel  (Antonin Houska <ah@cybertec.at>)
Список pgsql-hackers

On Fri, Jul 15, 2022 at 5:00 PM Richard Guo <guofenglinux@gmail.com> wrote:
On Fri, Jul 15, 2022 at 4:03 PM Richard Guo <guofenglinux@gmail.com> wrote:
On Thu, Jul 14, 2022 at 10:02 PM Antonin Houska <ah@cybertec.at> wrote:
I'd prefer a test that demonstrates that the Gather node at the top of the
"subproblem plan" is useful purely from the *cost* perspective, rather than
due to executor limitation.

This patch provides an additional path (Gather atop of subproblem) which
was not available before. But your concern makes sense that we need to
show this new path is valuable from competing on cost with other paths.

How about we change to Nested Loop at the topmost? Something like:

Maybe a better example is that we use a small table 'c' to avoid the
Gather node above scanning 'c', so that the path of parallel nestloop is
possible to be generated.

Update the patch with the new test case.

Thanks
Richard 
 
Вложения

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

Предыдущее
От: Martin Kalcher
Дата:
Сообщение: Re: Proposal to introduce a shuffle function to intarray extension
Следующее
От: Martin Kalcher
Дата:
Сообщение: Re: Proposal to introduce a shuffle function to intarray extension