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 FooProjectRule (that
converts a LogicalProject to a FooProject) and a FooFilterRule, but forgot a
FooAggregateRule. (Or perhaps created a FooAggregateRule but forgot to make it
a ConverterRule, or forgot to register it.)
I’d love it if there were a solution to this very common case, that there is no
link from the logical stack
Aggregate
|
Project
|
Filter
|
Scan
to the required physical plan
FooToJdbc
|
FooAggregate
|
FooProject
|
FooFilter
|
FooScan
If there was an automated way to detect that condition it would be very useful.
But it’s a hard problem, because of course that FooAggregate isn’t there; there
is a hole in the plan where it should be.
Julian
> On Jan 31, 2019, at 3:21 PM, Stamatis Zampetakis <[email protected]> wrote:
>
> @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 all
> rules work well together.
>
> If you want high guarantees that there will be no unexpected surprises then
> try to minimize the rules you are using. Another alternative would be to
> give as an input to the VolcanoPlanner already an executable plan and apply
> only rules that do not change the convention. In principle this should
> never lead to a CannotPlanException.
>
> @Vladimir:
> I would prefer something that is not tight to a particular IDE.
>
> I also think it would be nicer to show Sets / Subsets as nested charts.
> Plus, I think it would help if the plan was drawn in a top-down fashion and
> not towards any direction.
>
> Best,
> Stamatis
>
>
>
> Στις Τρί, 29 Ιαν 2019 στις 7:07 π.μ., ο/η Kenneth Knowles <[email protected]>
> έγραψε:
>
>> 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 consider any
>> options if they improve usability.
>>
>> Perhaps one way to explain a CannotPlanException might be to present a set
>> of additional rules that would be required to reach a plan, and try to make
>> them somehow "reasonable" or "minimal". For example if you wanted
>> convention BAZ but didn't have a converter from FooSomeRel to BazSomeRel it
>> would be great to be able to say that. It could also be useful to highlight
>> rules where the structure matched but side conditions did not.
>>
>> Kenn
>>
>> On Mon, Jan 28, 2019 at 8:16 AM Vladimir Sitnikov <
>> [email protected]> wrote:
>>
>>>> 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. jgraphx-based)
>>>
>>>> Anton Haidai did a nice visualizer [1] for sets, subsets, and rels
>> using
>>>
>>> Thanks for pointing it.
>>> My initial though was to visualize Sets / SubSets as nested charts.
>>>
>>>> perhaps the path to a
>>>> generated graph created in a temp directory could be part of the
>>>> exception
>>>
>>> Or a base64-encoded blob with a link to "visualize it" )
>>>
>>> Vladimir
>>>
>>
