Fix dumb bug in tqueue.c

When I wrote this code originally, the intention was to recompute the
remapinfo only when the tupledesc changes.  This presumably only
happens once per query, but I copied the design pattern from other
DestReceivers.  However, due to a silly oversight on my part,
tqueue->tupledesc never got set, leading to recomputation for every
tuple.

This should improve the performance of parallel scans that return a
significant number of tuples.

Report by Amit Kapila; patch by me, reviewed by him.

diff --git a/src/backend/executor/tqueue.c b/src/backend/executor/tqueue.c
index 5735acf10e3356fa8def0ca9fc8aaf695492c5ca..d625b0d800ba50e34a79f941b56de58163ae5586 100644 (file)
--- a/src/backend/executor/tqueue.c
+++ b/src/backend/executor/tqueue.c
@@ -127,15 +127,15 @@ tqueueReceiveSlot(TupleTableSlot *slot, DestReceiver *self)
     * new tupledesc.  This is a strange test both because the executor really
     * shouldn't change the tupledesc, and also because it would be unsafe if
     * the old tupledesc could be freed and a new one allocated at the same
-    * address.  But since some very old code in printtup.c uses this test, we
-    * adopt it here as well.
+    * address.  But since some very old code in printtup.c uses a similar
+    * test, we adopt it here as well.
     */
-   if (tqueue->tupledesc != tupledesc ||
-       tqueue->remapinfo->natts != tupledesc->natts)
+   if (tqueue->tupledesc != tupledesc)
    {
        if (tqueue->remapinfo != NULL)
            pfree(tqueue->remapinfo);
        tqueue->remapinfo = BuildRemapInfo(tupledesc);
+       tqueue->tupledesc = tupledesc;
    }
 
    tuple = ExecMaterializeSlot(slot);