Since the new Scan has the same rowtype as the original scan node, and we get the column count from RowType, when we compute the cost for this scan operator, I wonder if may lead to the same cost for the new scan and old scan operator. As a result, the new scan may not be chosen by optiq optimizer.
Probably, we need modify the code of getting column count in DrillScanRel.computeSelfCost().
For RexLiteral, I think we had better use literal.getType().getSqlTypeName().
literal.getTypeName() returns a broad type of the literal. For example, all exact numbers, including integers have typeName "Decimal". If we use getTypeName(), then f[12.3] will also be pushed down into scan?
SEVERE: org.eigenbase.sql.validate.SqlValidatorException: Cannot apply 'ITEM' to arguments of type 'ITEM(<ANY>, <DECIMAL(3, 1)>)'. Supported form(s): <ARRAY>[<INTEGER>] <<<<<<<<<<<<<<<<<<<<<
But in any case, I'll make the change just in case.
Thanks for uncovering this. I am fixing this by removing the overridden visitLiteral() function as that is not required.
visitOver() in the super class takes care of visiting the operands. Tested (only the parsing) with the following query
SELECT f, SUM(f2['c2']) OVER (ROWS 3 PRECEDING), AVG(f3) OVER (ROWS 10 PRECEDING) FROM hbase.MyTable;
Projected column => [SchemaPath [`f`], SchemaPath [`f2`.`c2`], SchemaPath [`f3`]] - Aditya This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/21165/#review42453 On May 7, 2014, 9:34 a.m., Aditya Kishore wrote:
Aditya Kishore 2014-05-16, 15:15
Re: Review Request 21165: DRILL-626: Project push down into HBase scan