On Tue, Jan 23, 2018 at 9:38 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Wed, Jan 24, 2018 at 10:38 AM, Peter Geoghegan <p...@bowt.ie> wrote: >> The leader can go ahead and sort before calling something like a new >> WaitForParallelWorkersToAttach() function (or even >> WaitForParallelWorkersToFinish()). If we did add a >> WaitForParallelWorkersToAttach() function, then the performance hit >> would probably not be noticeable in practice. The >> parallel_leader_participates case would still work without special >> care (that's the main hazard that makes using a barrier seem >> unappealing). >> > > +1. I also think so. Another advantage is that even if one of the > workers is not able to start, we don't need to return an error at the > end of the query, rather we can detect that situation early and can > execute the query successfully. OTOH, if we are not convinced about > performance implications, then WaitForParallelWorkersToFinish should > serve the purpose which can be called at later point of time.
There is another disadvantage to just using WaitForParallelWorkersToFinish() to wait for nbtsort.c workers to finish (and not inventing a WaitForParallelWorkersToAttach() function, and calling that instead), which is: there can be no custom wait event that specifically mentions parallel CREATE INDEX. -- Peter Geoghegan