The fact that RelOptTableImpl creates directly an EnumerableTableScan seems to be a residue of the history (at the very beginning the class was only used to create EnumerableTableScan operators). I guess it is also an attempt to reduce the search space of the optimizer short-circuiting some LogicalTableScan to OtherTableScan transformations.
I also feel that generating a LogicalTableScan is more appropriate and this seems to be inline with the documentation of RelOptTable#toRel method. In all cases generating an EnumerableTableScan that is non-implementable does not seem to be a good idea. Best, Stamatis On Fri, Jan 3, 2020 at 1:36 PM Vladimir Sitnikov < [email protected]> wrote: > Hi, > > RelOptTableImpl#toRel uses if-else logic and it creates LogicalTableScan > or EnumerableTableScan depending on table instance and some properties. > Does anybody know why can't it always create LogicalTableScan and use rules > to convert it to EnumerableTableScan later? > > The current logic of creating EnumerableTableScan hurts for cases > like RelToSqlConverterStructsTest. > The test in question uses its own Table implementation (that is new > Table()), and the RelOptTableImpl#toRel tries to create EnumerableTableScan > out of it. > > It looks weird as the table could not be implemented anyway, so why don't > we create LogicalTableScan there? > > I have filed https://github.com/apache/calcite/pull/1721 to see what > breaks, but it does not seem right to me to EnumerableTableScan which is > known to be non-implementable. > > Vladimir >
