Thanks for the PR! HepPlanner does not perform cost-based decisions so for most use-cases I don't think it matters a lot what is the cost. For more advanced use-cases, where there might be rules that use CumulativeCost and other kinds of such metadata, the HepPlanner can be configured with another cost factory.
I don't see a big reason to change the API of RelOptCost#getRows, the callers who ask for cumulative cost should know what to expect. Apart from that rejected rows and other metrics can be added if necessary. Although it is nice to account for CPU and IO in the cost model, it has been shown [1] that for main memory settings even a simple cost model based entirely on cardinality estimations can work fine for many queries. For those interested [1] has also an interesting discussion regarding Postgres cost model. Best, Stamatis [1] http://www.vldb.org/pvldb/vol9/p204-leis.pdf On Sun, Jan 5, 2020 at 2:12 PM Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > In the meantime, I've created a PR that updates VolcanoCost: > https://github.com/apache/calcite/pull/1722 > > Vladimir >
