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);