Said like that it looks like a bug. I think the best would be to reproduce the exception as a unit test in HepPlannerTest [1], RelOptRulesTest [2], or PlannerTest [3] so that we could understand better the use case.
[1] https://github.com/apache/calcite/blob/master/core/src/test/java/org/apache/calcite/test/HepPlannerTest.java [2] https://github.com/apache/calcite/blob/master/core/src/test/java/org/apache/calcite/test/RelOptRulesTest.java [3] https://github.com/apache/calcite/blob/master/core/src/test/java/org/apache/calcite/tools/PlannerTest.java On Thu, May 2, 2019 at 7:56 AM Mark Pasterkamp <[email protected]> wrote: > I don't, I would assume that the HepPlanner.findBestExp() calculates the > cost somewhere down the line > > On Thu, May 2, 2019, 03:31 Yuzhao Chen <[email protected]> wrote: > > > Why you care about cost when use HepPlanner ? The HepPlanner is aimed for > > some deterministic planning rules, we usually do not need cost in Hep. > Some > > exceptions like Join reorder may need a cost. > > > > What kind of planning promotion you did ? I'm kind of curious about it. > > > > Best, > > Danny Chan > > 在 2019年5月1日 +0800 PM9:27，Mark Pasterkamp <[email protected] > > >，写道： > > > Dear all, > > > > > > While playing around with the HepPlanner I ran into an issue where the > > > planner wants to rewrite a query with a union rewrite. When the > > > RelMetaDataQuery computes the cost, the cost instance is a VolcanoCost. > > > Then when it tries to calculate the cost of one of the union's operands > > it > > > is a RelCostImpl which results in the ClassCastException. > > > > > > How would I go about solving this issue? As far as my knowledge goes, I > > am > > > not able to change the costhandler of the RelMetaDataQuery. Another > > > approach I could see is removing the cast in the VolcanoCost class, > but I > > > would hope I do not have to do that. > > > > > > > > > With kind regards, > > > > > > Mark > > >
