Обсуждение: BUG #19372: Scan operator maybe output unnecessary columns to the upper-layer operators

The following bug has been logged on the website:

Bug reference:      19372
Logged by:          yao jia
Email address:      yaojia_0809@163.com
PostgreSQL version: 18.0
Operating system:   linux  centos
Description:

The scan operator maybe output unnecessary columns to the upper-layer
operators. This seems like redundant work because the upper-layer operators
don't need these column data at all. This undoubtedly increases execution
overhead.
Is this behavior intentionally designed this way, or is it an unintended
side effect? Should the unnecessary column output be eliminated?

Here is a specific example：columns [jname, c, d, e] are useless for group
and final output, but they are in seqscan's output
postgres=# create table hash_hash_jade22 (hjid int,rjid int,jname varchar, c
varchar, d varchar, e varchar);
CREATE TABLE
postgres=# explain verbose select min(hjid) from hash_hash_jade22 group by
rjid;
                                   QUERY PLAN
--------------------------------------------------------------------------------
 HashAggregate  (cost=17.35..19.35 rows=200 width=8)
   Output: min(hjid), rjid
   Group Key: hash_hash_jade22.rjid
   ->  Seq Scan on public.hash_hash_jade22  (cost=0.00..14.90 rows=490
width=8)
         Output: hjid, rjid, jname, c, d, e

On Wed, 7 Jan 2026 at 21:49, PG Bug reporting form
<noreply@postgresql.org> wrote:
> The scan operator maybe output unnecessary columns to the upper-layer
> operators. This seems like redundant work because the upper-layer operators
> don't need these column data at all. This undoubtedly increases execution
> overhead.
> Is this behavior intentionally designed this way, or is it an unintended
> side effect? Should the unnecessary column output be eliminated?

It's working as intended. This is useful for HeapAm as TupleTableSlots
can carry a pointer to the tuple on the page and deform only up to the
last column that's required.  If you want the Seq Scan to only have
the columns required at the scan level, then that requires a
projection operation at the scan level. In your query, only columns 1
and 2 will be deformed from the tuple and that'll happen during the
HashAggregate. No tuple deformation is required before that in your
query.

Where this behaviour isn't ideal is for table AMs such as column
stores. Ideally, we'd leave this up to the table AM to state if it's
useful or not, but we currently don't have that ability. I'm surprised
nobody has asked for that yet.

David