On Mon, Aug 28, 2017 at 6:35 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> but probably we should think of a more arm's-length way to do it.
> Maybe parallel_aware should have more than two values, depending
> on whether the result of the node is context-dependent or not.
My original intent for the parallel_aware flag was for it to signal
whether the plan node was going to do something functionally different
when in parallel mode. For scans, that's come to mean "partition the
input among the workers", and there doesn't seem to be any other
sensible meaning. I don't have a good idea what it's going to mean
for non-scan nodes yet. Parallel Hash will be the first non-parallel
aware scan node, and it uses it to mean that the hash table in dynamic
shared memory, so that the inner side can be partial (which is
otherwise not possible). I'm guessing that is going to be a common
meaning for nodes that store stuff - it's easy to imagine Parallel
Materialize, Parallel Sort, Parallel HashAggregate with similar
semantics. There's also a proposed patch for Parallel Append where it
signals that DSM is being used to coordinate task scheduling and load
balancing.
It seems likely the whole concept of parallel_aware is only only a
zero-order approximation to what we really want. This bug is, IMHO,
the first really tangible evidence of the concept creaking around the
edges, but I've kind of had a feeling for a while that it wasn't
likely to be problem-free. I'm still not sure exactly what the right
answer will turn out to be.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company