I'm not convinced there aren't better alternatives, so I hope we can
continue to explore this. Specifically with respect to the statement
"It means there's not enough rules to produce the node with desired
properties", it would be great if we could more clearly identify what
properties the missing
Julian>It really bugs me that it takes a couple of hours of careful reading
of the log to figure out that for your new Foo Convention you have a
FooProjectRule
I guess this case can be improved by searching the leaf empty subsets.
I've filed https://github.com/apache/calcite/pull/1024 which does
It bugs me, too, that you sometimes get a CannotPlanException. (Usually “you”
as a developer of a planner, less often “you” as an end user, but not never.)
It really bugs me that it takes a couple of hours of careful reading of the log
to figure out that for your new Foo Convention you have a
@Kenneth:
A CannotPlanException indicates a bug either in the planner it self either
in the way that is initialised. As in every program there is no better way
to ensure that there no bugs other than testing. The correctness of the
VolcanoPlanner highly depends on the rules that are used since not
On a previous thread, I asked about this, as it is not just for debugging
but user-facing. It seems there is no reliable way to build a tool on top
of Calcite that gives high assurance of avoiding CannotPlanException
reaching a user.
Are other planners better for this? Beam SQL would probably
> toGraphViz
A bit of problem with GraphViz is it is more or less static.
However sometimes it might be great to move/expand/collapse nodes. For
instance, for "Project" it makes sense to show expressions.
So I'm a bit puzzled between "JS-based chart" vs GraphViz vs a plugin
for IntelliJ (e.g.
Hi Vladimir,
Anton Haidai did a nice visualizer [1] for sets, subsets, and rels using
Calcite's logging mechanism.
Maybe it suits your needs.
Best,
Stamatis
[1] https://github.com/anha1/apache-calcite-trace-analyzer
Στις Δευ, 28 Ιαν 2019 στις 1:01 μ.μ., ο/η Vladimir Sitnikov <
Hi,
I've been debugging VolcanoPlanner for quite some time recently, and
it looks like its transparency leaves much to be desired.
Key issues I've run into:
1) It is complicated to understand "what happens" during rule execution.
call.transformTo(..) is used a lot, and it is really hard to keep
