Re: Batching in executor

From: xliu19163(at)gmail(dot)com
To: Denis Smirnov <darthunix(at)gmail(dot)com>
Cc: Amit Langote <amitlangote09(at)gmail(dot)com>, Tatsuya Kawata <kawatatatsuya0913(at)gmail(dot)com>, Mats Kindahl <mats(dot)kindahl(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Batching in executor
Date: 2026-09-08 08:50:17
Message-ID: CAPPb3ygXG1J=RagMkKJwetcG8vUHZyRCKMKnQDKyJOCXpzfZhw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Denis, Amit, and Tatsuya,

I have been following this thread, especially the recent discussion around
filter_attrs/output_attrs, getcolumnattr(Bitmapset), and staged
materialization.

I am considering working on a narrow, standalone piece: derive the
attributes needed by an ordinary SeqScan (output plus quals) during
executor initialization, and make that scan-lifetime information
available at scan setup. The initial scope would be SeqScan only, with
no batch API implementation, predicate/limit pushdown, index or bitmap
scans, or DML paths.

Before starting, I wanted to check for overlap:

1. Is anyone already implementing the TupleBatchRequest /
filter_attrs/output_attrs or getcolumnattr(Bitmapset) direction?
2. Would a standalone pre-batching patch that provides required
attributes at scan setup be useful, or should this be designed only
as part of the slot batch interface?
3. If standalone work makes sense, would you prefer passing the request
to beginscan(), or attaching it to the scan slot or descriptor?

I saw Amit's earlier point that this is scan-lifetime state and can be
developed independently of returning batches, but the later slot-based
discussion appears to overlap, so I wanted to coordinate before writing
a patch.

Thanks,
Xiaoyu

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2026-09-08 08:58:15 Re: Offline data checksum changes can cause incorrect checksum state on standbys
Previous Message Peter Eisentraut 2026-09-08 08:48:29 Re: FOR PORTION OF bounds not coerced in PREPARE