Re: Parallel Append can break run-time partition pruning

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: Parallel Append can break run-time partition pruning
Дата
Msg-id CAApHDvptEEuhidhRG1bPaSmBLx6TeTjZjNJH3eZogVbjc0Z9-Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Parallel Append can break run-time partition pruning  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Parallel Append can break run-time partition pruning
Re: Parallel Append can break run-time partition pruning
Список pgsql-hackers
On Thu, 23 Apr 2020 at 11:11, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> David Rowley <dgrowleyml@gmail.com> writes:
> > Given the same set of paths, when would a non-parallel append be
> > cheaper than a parallel one?
>
> Well, anytime the parallel startup cost is significant, for starters.
> But maybe we account for that at some other point, like when building
> the Gather?

Yeah. There's no mention of parallel_setup_cost or parallel_tuple_cost
in any of the Append costing code. Those are only applied when we cost
Gather / GatherMerge At the point Amit and I are talking about, we're
only comparing two Append paths. No Gather/GatherMerge in sight yet,
so any additional costs from those is not applicable.

If there was some reason that a Parallel Append could come out more
expensive, then maybe we could just create a non-parallel Append using
the same subpath list and add_partial_path() it. I just don't quite
see how that would ever win though. I'm willing to be proven wrong
though.

David



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Parallel Append can break run-time partition pruning
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Parallel Append can break run-time partition pruning