Read from the same worker repeatedly until it returns no tuple.

The original coding read tuples from workers in round-robin fashion,
but performance testing shows that it works much better to read enough
to empty one queue before moving on to the next.  I believe the
reason for this is that, with the old approach, we could easily wake
up a worker repeatedly to write only one new tuple into the shm_mq
each time.  With this approach, by the time the process gets scheduled,
it has a decent chance of being able to fill the entire buffer in
one go.

Patch by me.  Dilip Kumar helped with performance testing.

diff --git a/src/backend/executor/nodeGather.c b/src/backend/executor/nodeGather.c
index f32da1e2352e7061d1535f4da968386de7785906..db5883d28ef2e59f5944f7af6eccef9943ef3244 100644 (file)
--- a/src/backend/executor/nodeGather.c
+++ b/src/backend/executor/nodeGather.c
@@ -359,14 +359,20 @@ gather_readnext(GatherState *gatherstate)
            continue;
        }
 
-       /* Advance nextreader pointer in round-robin fashion. */
-       gatherstate->nextreader =
-           (gatherstate->nextreader + 1) % gatherstate->nreaders;
-
        /* If we got a tuple, return it. */
        if (tup)
            return tup;
 
+       /*
+        * Advance nextreader pointer in round-robin fashion.  Note that we
+        * only reach this code if we weren't able to get a tuple from the
+        * current worker.  We used to advance the nextreader pointer after
+        * every tuple, but it turns out to be much more efficient to keep
+        * reading from the same queue until that would require blocking.
+        */
+       gatherstate->nextreader =
+           (gatherstate->nextreader + 1) % gatherstate->nreaders;
+
        /* Have we visited every TupleQueueReader? */
        if (gatherstate->nextreader == waitpos)
        {