Robert Haas <robertmhaas@gmail.com> writes:
> On Sun, Jun 19, 2016 at 10:23 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Personally, I'm +1 for such tinkering if it makes the feature either more
>> controllable or more understandable. After reading the comments at the
>> head of nodeGather.c, though, I don't think that single_copy is either
>> understandable or useful, and merely renaming it won't help. Apparently,
>> it runs code in the worker, except when it doesn't, and even when it does,
>> it's absolutely guaranteed to be a performance loss because the leader is
>> doing nothing. What in the world is the point?
> The single_copy flag allows a Gather node to have a child plan which
> is not intrinsically parallel.
OK, but I'm very dubious of your claim that this has any use except for
testing purposes. It certainly has no such use today. Therefore, the
behavior of falling back to running in the leader seems like an
anti-feature to me. If we want to test running in a worker, then we
want to test that, not maybe test it.
I propose that the behavior we actually want here is to execute in
a worker, full stop. If we can't get one, wait till we can. If we
can't get one because no slots have been allocated at all, fail.
That would make the behavior deterministic enough for the regression
tests to rely on it.
And while I don't know what this mode should be called, I'm pretty sure
that neither "single_copy" nor "pipeline" are useful descriptions.
regards, tom lane