Fix dumb bug in tqueue.c

robertmhaas · robertmhaas · commit adeee9748660 · 2015-11-18T08:25:33.000-05:00
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-&gt;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
@@ -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);
