What we have done in the past is push filters into a scan and alter the costing (and estimated row count). In cases where the filter or portions of the filter can be applied against partitioning columns, you prune partitions and use a new row count estimate/cost estimate based on the reduced partition set.
On Fri, Dec 10, 2021 at 10:25 AM Maxim Gramin <[email protected]> wrote: > I assume that some of the filter conditions (which are involved in the > choice of partitions ) may by pushdown'ed to TableScan > > On Fri, Dec 10, 2021 at 7:29 PM Константин Новиков > <[email protected]> wrote: > > > > > Hi, > > > > Given some partitioned storage, we can omit the scan of some partitions > > when a filter is present. How can the lower cost of the scan be > > represented? As far as I can tell the current approach only allows > > providing a single cost for the TableScan and Filter can only add to > > that. Should my implementation provide a rule that combines > > Filter+TableScan? > > >
