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