Stamatis>HepPlanner does not perform cost-based decisions so for most use-cases I
It seems to have some cost-based decisions, so providing ill-defined cost seems wrong. Well, let's see how new VolcanoCost would work, and then we could discuss Hep. Stamatis>Although it is nice to account for CPU and IO in the cost model, it has Stamatis>been shown [1] I don't think the article applies here. Calcite's Volcano optimizer tends to produce lots of Project and Filter relations, and it is important to weight them appropriately, otherwise, it would endlessly generate dumb projects. Stamatis>[1] has also an interesting discussion regarding Postgres Stamatis>cost model. PostgreSQL cost model has _two_ cost values for each relation: startup cost and total cost (see https://www.postgresql.org/docs/12/sql-explain.html ) However, the article does not mention the difference between startup and total cost, thus it does not look like they properly discuss PostgreSQL cost model. I'm not sure how often startup cost is useful, but it might help for cases like "(...) limit 5" For example, currently, we don't really use "offset/limit" for cost computation. And we do not have a clear answer to that. On the other hand, if each relation could supply its "startup cost", then the cost of "limit" would be startupCost + totalCost*(limit / totalRows) Vladimir
