osdir.com

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Best practice for exhaustive planning


For most queries, the only thing you should need to implement is a scan and
the rest can usually be implemented by Calcite. It would be good if you
have a specific example of a query that fails.

--
Michael Mior
mmior@xxxxxxxxxxxx


Le mar. 22 mai 2018 à 19:01, Kenneth Knowles <klk@xxxxxxxxxx.invalid> a
écrit :

> Bumping this, as it ended up in spam for some people.
>
> Kenn
>
> On Tue, May 15, 2018 at 9:26 AM Kenneth Knowles <klk@xxxxxxxxxx> wrote:
>
> > Hi all,
> >
> > Beam SQL uses Calcite for parsing and (naive) planning. Currently it is
> > pretty easy to write a SQL query that parses and causes a "could not
> plan"
> > dump when we ask the planner to convert things to the Beam calling
> > convention. One current example is using UNNEST on a column to yield a
> > LogicalCorrelate + Uncollect.
> >
> > There may obviously always be bits we don't support, but we'd like to
> > ensure that the user encounters a careful error message rather than a
> > planner dump. Is there a best practice for ensuring that we have covered
> > all the cases? Is it just "everything name Logical*" or is there
> something
> > more clever?
> >
> > And if this question demonstrates that we are using Calcite entirely
> > wrong, let us know :-)
> >
> > Kenn
> >
>