Re: Parallel append plan instability/randomness - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Parallel append plan instability/randomness
Date
Msg-id 4160.1515430678@sss.pgh.pa.us
Whole thread Raw
In response to Re: Parallel append plan instability/randomness  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Parallel append plan instability/randomness
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: Parallel append plan instability/randomness
Next
From: Ken Huffman
Date:
Subject: RE: PL/Python SD dict wiped?