Re: Parallel append plan instability/randomness

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Parallel append plan instability/randomness
Дата
Msg-id 4160.1515430678@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Parallel append plan instability/randomness  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Parallel append plan instability/randomness
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Jan 8, 2018 at 11:42 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> More generally, I wonder if
>> it wouldn't be better to implement this behavior at runtime rather
>> than plan time.

> Ignoring some details around partial vs. non-partial plans, that's
> pretty much what we ARE doing, but to make it efficient, we sort the
> paths at plan time so that those choices are easy to make at runtime.
> If we didn't do that, we could have every worker sort the paths at
> execution time instead, or have the first process to arrive perform
> the sort and store the results in shared memory while everyone else
> waits, but that seems to be more complicated and less efficient, so I
> don't understand why you're proposing it.

The main bit of info we'd have at runtime that we lack at plan time is
certainty about the number of available workers.  Maybe that doesn't
really add anything useful to the order in which subplans would be doled
out; not sure.

            regards, tom lane


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Parallel append plan instability/randomness
Следующее
От: Ken Huffman
Дата:
Сообщение: RE: PL/Python SD dict wiped?