Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit adeee97

Browse files
committed
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.
1 parent 5f10b7a commit adeee97

File tree

1 file changed

+4
-4
lines changed

1 file changed

+4
-4
lines changed

src/backend/executor/tqueue.c

+4-4
Original file line numberDiff line numberDiff line change
@@ -127,15 +127,15 @@ tqueueReceiveSlot(TupleTableSlot *slot, DestReceiver *self)
127127
* new tupledesc. This is a strange test both because the executor really
128128
* shouldn't change the tupledesc, and also because it would be unsafe if
129129
* the old tupledesc could be freed and a new one allocated at the same
130-
* address. But since some very old code in printtup.c uses this test, we
131-
* adopt it here as well.
130+
* address. But since some very old code in printtup.c uses a similar
131+
* test, we adopt it here as well.
132132
*/
133-
if (tqueue->tupledesc != tupledesc ||
134-
tqueue->remapinfo->natts != tupledesc->natts)
133+
if (tqueue->tupledesc != tupledesc)
135134
{
136135
if (tqueue->remapinfo != NULL)
137136
pfree(tqueue->remapinfo);
138137
tqueue->remapinfo = BuildRemapInfo(tupledesc);
138+
tqueue->tupledesc = tupledesc;
139139
}
140140

141141
tuple = ExecMaterializeSlot(slot);

0 commit comments

Comments
 (0)