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 <[email protected]> wrote: > Denis Smirnov <[email protected]> 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
