[PATCH] Remove unused scan tuple slots from Sort, IncrementalSort, Material and Memoize

From: Tatsuya Kawata <kawatatatsuya0913(at)gmail(dot)com>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: [PATCH] Remove unused scan tuple slots from Sort, IncrementalSort, Material and Memoize
Date: 2026-08-12 04:24:46
Message-ID: CAHza6qeig9DYsa16doLugsAuL90ORiKgLX43hs0Cf9BgqghiRg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Sort, IncrementalSort, Material and Memoize all call
ExecCreateScanSlotFromOuterPlan() during initialization to allocate a
scan tuple slot, but none of them ever reads that slot. The attached
patch removes those calls. This is a small cleanup; it does not improve
performance or memory usage. The point is to drop initialization work
that nothing uses, together with a comment that no longer matches the
code.

## What is unused

Via ExecInitScanTupleSlot(), ExecCreateScanSlotFromOuterPlan() sets four
more fields besides the slot itself:

scanstate->ss_ScanTupleSlot = ExecAllocTableSlot(...);
scanstate->ps.scandesc = tupledesc;
scanstate->ps.scanopsfixed = tupledesc != NULL;
scanstate->ps.scanops = tts_ops;
scanstate->ps.scanopsset = true;

None of these five is reachable from any reader in the four nodes above.
Where such a node needs to deal with an input tuple it has its own way
of doing so; Sort, for instance, keeps nothing of its own and hands the
child's slot straight to tuplesort.

This is unlike Agg, WindowAgg and Group. Those three do reuse
ss_ScanTupleSlot as a working buffer for an input tuple, which they then
make visible to expression evaluation via the expression context
(firstSlot in nodeAgg.c, for example), so they are left alone here.

The patch also drops this line from MaterialState's header comment in
execnodes.h:

ss.ss_ScanTupleSlot refers to output of underlying plan.

The identical wording in AggState's comment is still accurate, so that
one is kept.

## How it got there

These calls look like a leftover from the days when Sort and Material
really were scan nodes. Back then they wrote the output of the subplan
into a temporary relation with heap_insert() and read it back with
heap_beginscan(), so ss_currentRelation and ss_ScanTupleSlot were used
for their stated purpose. When that approach was dropped, it seems only
the allocation was left behind.

make check-world passes.
Patch attached.

Regards,
Tatsuya Kawata

Attachment Content-Type Size
v1-0001-Remove-unused-scan-tuple-slots-from-Sort-Incremen.patch application/octet-stream 4.0 KB

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2026-08-12 04:26:46 Re: [PATCH] Avoid uninitialized-value error in poll_query_until timeout diagnostic
Previous Message Fujii Masao 2026-08-12 04:22:44 Re: Fix small psql slash option leaks