On Fri, Jan 26, 2018 at 1:30 AM, Peter Geoghegan <p...@bowt.ie> wrote: > I had imagined that WaitForParallelWorkersToAttach() would give me an > error in the style of WaitForParallelWorkersToFinish(), without > actually waiting for the parallel workers to finish.
+1. If we're going to go that route, and that seems to be the consensus, then I think an error is more appropriate than returning an updated worker count. On the question of whether this is better or worse than using barriers, I'm not entirely sure. I understand that various objections to the Barrier concept have been raised, but I'm not personally convinced by any of them. On the other hand, if we only have to call WaitForParallelWorkersToAttach after the leader finishes its own sort, then there's no latency advantage to the barrier approach. I suspect we might still end up reworking this if we add the ability for new workers to join an index build in medias res at some point in the future -- but, as Peter points out, maybe the whole algorithm would get reworked in that scenario. So, since other people like WaitForParallelWorkersToAttach, I think we can just go with that for now. I don't want to kill this patch with unnecessary nitpicking. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
