On Fri, Jan 26, 2018 at 1:30 AM, Peter Geoghegan <pg@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
