calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Pasterkamp <markpasterkamp1...@gmail.com>
Subject Re: ClassCastException RelOptCostImpl VolcanoCost while using HepPlanner
Date Thu, 02 May 2019 15:47:33 GMT
Hi Stamatis,

I have tried to recreate the issue but I have not been able to do that. I
was however able to create a new exception which I don't quite understand.
The error happened when calcite was creating a union rewriting using
materialized views. But trying to recreate this situation gave me another
interesting one.
This time, the planner rewrites one of the children nodes into itself I
would assume which causes a stack overflow. The method itself can be found
here:

https://github.com/mpasterkamp/calcite/blob/768b7928dbde5f6f9775a1119e7466d8eafafb4b/core/src/test/java/org/apache/calcite/test/HepPlannerTest.java#L312

Perhaps I am doing something wrong, perhaps not? I am not knowledgeable
enough about this to understand why this is happening. Wish I could help
more for that.

Also, while investigating this issue I found another interesting artifact
in de source code of the VolcanoCost. A lot of methods in this class have
an "if (true)"-statement like here:

https://github.com/apache/calcite/blob/4b4d8037c5073e4eb5702b12bc4ecade31476616/core/src/main/java/org/apache/calcite/plan/volcano/VolcanoCost.java#L100

Now I was just curious, is there any reason for this to be there that you
know of?

Thank you for responding and congratulations for your recent promotions.


With kind regards,

Mark


On Thu, 2 May 2019 at 14:58, Stamatis Zampetakis <zabetak@gmail.com> wrote:

> 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 <
> markpasterkamp1994@gmail.com>
> 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 <yuzhao.cyz@gmail.com> 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 <markpasterkamp1994@gmail.com
> > > >,写道:
> > > > 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
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message