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 > >
