On Mon, Sep 11, 2017 at 9:25 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: > I think the patch stores only non-partial paths in decreasing order, > what if partial paths having more costs follows those paths?
The general picture here is that we don't want the leader to get stuck inside some long-running operation because then it won't be available to read tuples from the workers. On the other hand, we don't want to just have the leader do no work because that might be slow. And in most cast cases, the leader will be the first participant to arrive at the Append node, because of the worker startup time. So the idea is that the workers should pick expensive things first, and the leader should pick cheap things first. This may not always work out perfectly and certainly the details of the algorithm may need some refinement, but I think the basic concept is good. Of course, that may be because I proposed it... Note that there's a big difference between the leader picking a partial path and the leader picking a non-partial path. If the leader picks a partial path, it isn't committed to executing that path to completion. Other workers can help. If the leader picks a non-partial path, though, the workers are locked out of that path, because a single process must run it all the way through. So the leader should avoid choosing a non-partial path unless there are no partial paths remaining. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
