Thanks Stamatis, will try this. On Tue, Mar 12, 2019 at 9:52 PM Stamatis Zampetakis <[email protected]> wrote:
> Hi Anupam, > > After the merge of Calcite-2827 [1] to master, it is possible to get as an > ouput of the volcano planner a logical plan. > Maybe using this new feature you can use the MV substitution without > introducing physical operators. > > Best, > Stamatis > > [1] https://issues.apache.org/jira/browse/CALCITE-2827 > > Στις Τρί, 12 Μαρ 2019 στις 1:57 μ.μ., ο/η Anupam Aggarwal < > [email protected]> έγραψε: > > > Thanks Julian. > > > > I am using VolcanoPlanner to do the MV rewrite, to get an optimised > relNode > > (and then convert to Sql) > > (wasn't able to get the HepPlanner do the MV substitution using a logical > > plan) > > Logged a JIRA (will open a PR shortly) > > https://jira.apache.org/jira/projects/CALCITE/issues/CALCITE-2915 > > > > Thanks > > Anupam > > > > > > On Tue, Mar 12, 2019 at 2:28 AM Julian Hyde <[email protected]> wrote: > > > > > It’s a bit unusual that you are converting physical algebra > (enumerable) > > > to SQL. > > > > > > EnumerableLimit only exists in physical algebra. > > > > > > In logical algebra, there is Sort, which includes an optional limit and > > > offset. So, you could perhaps convert EnumerableLimit to Sort before > > > calling RelToSqlConverter. Or add a handler to RelToSqlConverter that > > does > > > this internally. > > > > > > In any case, please log a JIRA case. Contributions welcome. > > > > > > Julian > > > > > > > > > > On Mar 11, 2019, at 1:20 PM, Anupam Aggarwal < > > [email protected]> > > > wrote: > > > > > > > > Hi, > > > > > > > > We are using calcite to do MV rewrite, for we convert the original > sql > > > to > > > > a relNode, optimize the relNode and reconvert it back to Sql (using > > > > RelToSqlConverter) > > > > > > > > Currently a query like this > > > > > > > > *Select * from foo.bar where limit 10 ; * > > > > > > > > Results in the following plan (after a MV rewrite to a different > table) > > > > > > > > EnumerableLimit(fetch=[1]): rowcount = 1.0, cumulative cost = {1.0 > > rows, > > > > 2.0 cpu, 0.0 io}, id = 303 > > > > EnumerableTableScan(table=[[viewSchema, barView]]): rowcount = 1.0, > > > > cumulative cost = {0.0 rows, 1.0 cpu, 0.0 io}, id = 176 > > > > > > > > While converting the relNode to sql using RelToSqlConverter we get an > > > > exception saying > > > > Caused by: java.lang.reflect.InvocationTargetException > > > > Caused by: java.lang.AssertionError: Need to implement > > > > org.apache.calcite.adapter.enumerable.EnumerableLimit > > > > > > > > Seems like RelToSqlConverter does not handle EnumerableLimit , Is > this > > a > > > bug ? > > > > The fix is adding a visit method to RelToSqlConverter with > > > > EnumerableLimit as the function argument. > > > > > > > > > > > > public Result visit(EnumerableLimit e) { > > > > Result x = visitChild(0, e.getInput()); > > > > Builder builder = x.builder(e, Clause.FETCH); > > > > > > > > if (e.fetch != null) { > > > > builder = x.builder(e, Clause.FETCH); > > > > builder.setFetch(builder.context.toSql(null, e.fetch)); > > > > x = builder.result(); > > > > } > > > > if (e.offset != null) { > > > > builder = x.builder(e, Clause.OFFSET); > > > > builder.setOffset(builder.context.toSql(null, e.offset)); > > > > x = builder.result(); > > > > } > > > > return x; > > > > } > > > > > > > > Found some relevant discussion here - > > > > https://jira.apache.org/jira/browse/CALCITE-1003. > > > > Can you please help in understanding if this handling is correct? (or > > > > if there is a better way ) > > > > > > > > Thanks > > > > Anupam > > > > > > > > >
