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? -- Antonin Houska Web: https://www.cybertec-postgresql.com
