On Mon, Aug 15, 2016 at 6:55 AM, Robert Haas <robertmh...@gmail.com> wrote: > A sort of dumb way of handling all this is to assume that once a > worker joins the hash join, it won't go off and do anything else until > the hash join is done. Under that assumption, you just need some sort > of BarrierAttach() operation; workers that have never attached the > barrier aren't participating in the hash join at all and so they are > irrelevant - and now you know how many workers you need to await, > because you can keep a count how many have attached. Perhaps you > simply turn away any workers that arrive after batch 0 is complete.
Is that really so bad? In general, I don't tend to think of workers as the cost to worry about. Rather, we should be concerned about the active use of CPU cores as our major cost. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
