Hi,
On Thu, Aug 28, 2025 at 02:57:02AM +0500, Kirill Reshke wrote:
> Hi!
> I was also always wondering if something like quals pushing can be
> implemented in Postgres. It is indeed very beneficial for Column-based
> processing in MPP databases, Greenplum and Cloudberry to name a few. I
> did my own micro-research a while ago (while working on some
> Cloudberry features), so here are my thoughts on the subject.
>
> What this patchset is doing, is passing ScanKeys directly to tableam
> somewhat blindly. In speedups processing execution-phase. While I do
> not have strong objections against this approach, I suspect this
> breaks some layers of abstractions and *silent* (or maybe documented)
> agreements of what are responsibilities of TableAM functions. So,
> passing ScanKeys directly to TAM is used on HEAD for catalog-access
> only. Correct me if I'm wrong. For all other types of relation each
> query is planned, which includes
>
> (1) building data access patch thought various data access methods (indexes)
> (2) Decide for each Qual which indexes can be used to satisfy this qual
> (3) Using Cost Model for filtering best options
>
> All of this can not be done with your approach?
>
> Cost model can give hints to the optimizer that this TAM will process
> some qual much faster than any by-index access. Smart cost
> model/optimizer can realise that selecting only few of all attributes
> from column-orietired relation + filter when using SIMD etc can be
> really cheap.
>
> So maybe the good shape of this patch would be something that could
> choose between seqscan and indexscan in planner time?
Thank you for your quick feed back.
Exact, this patch does not add/reduce any cost when some quals are
planned to be pushed down. I agree with you that it would be nice
(necessary?) to have this. I think the table AM API should provide, via
new APIs, cost estimation in case of table scan and considering the cost
of evaluating the quals, if any.
Best regards,
--
Julien Tachoires
