| From: | Antonin Houska <ah(at)cybertec(dot)at> |
|---|---|
| To: | Denis Smirnov <darthunix(at)gmail(dot)com> |
| Cc: | Amit Langote <amitlangote09(at)gmail(dot)com>, Junwang Zhao <zhjwpku(at)gmail(dot)com>, cca5507 <cca5507(at)qq(dot)com>, Daniil Davydov <3danissimo(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Tomas Vondra <tomas(at)vondra(dot)me> |
| Subject: | Re: Batching in executor |
| Date: | 2026-07-17 12:12:04 |
| Message-ID: | 30925.1784290324@localhost |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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?
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Antonin Houska | 2026-07-17 12:15:52 | Re: Batching in executor |
| Previous Message | Bohyun Lee | 2026-07-17 12:10:00 | Re: [PATCH] pg_upgrade: add --initdb option to create the new cluster automatically |