Re: Batching in executor

Hi,

I still haven't gotten a chance to review Denis's proposal and the
patches closely, but I wanted to second what Antonin wrote below.

On Fri, Jul 17, 2026 at 9:12 PM Antonin Houska <ah(at)cybertec(dot)at> wrote:
> Denis Smirnov <darthunix(at)gmail(dot)com> wrote:
>
> > I am not sure adding a new table AM callback for this is the right
> > direction, at least for this patch.
> >
> > My concern is that scan_getnextbatch still looks like a row-oriented
> > interface. For a Parquet-like AM, with columnar storage and block-level
> > filters such as bloom/fuse filters, the useful API would need to pass
> > down things like the required columns, pushed-down predicates, and maybe
> > a limit. Just asking the AM for the next batch of rows does not give the
> > storage layer enough information to avoid unnecessary work.
>
> Is there a reason not to include this information in the scan descriptor of
> particular AM?

Yeah, I think that information is better passed to beginscan() than to
getnextslot() or getnextbatch(). The scan descriptor is scan-lifetime
state, so telling the AM which columns and predicates it can use
belongs at scan setup; what the getnext* functions return per call is
a separate question. That work could be undertaken independently of
allowing them to return batches.

I'll try to reply properly on the rest of Denis's points later this week.

--
Thanks, Amit Langote