important given its impact on expression based in queries. On Sun, May 10, 2015 at 4:21 PM, Hsuan Yi Chu <hyi...@maprtech.com> wrote:
> I think so. The * column had been added to the container > after currentReader.next() was called. > > How do we priority this issue ? > > > > > On Sun, May 10, 2015 at 4:09 PM, Jacques Nadeau <jacq...@apache.org> > wrote: > > > I think it must be an issue in the ExtendedJsonReader (which is used by > the > > ValuesRel). It is probably the same as: > > > > https://issues.apache.org/jira/browse/DRILL-2906 > > > > Fixing 2906 should fix this. Can you try to determine issue? > > > > On Sun, May 10, 2015 at 4:03 PM, Hsuan Yi Chu <hyi...@maprtech.com> > wrote: > > > > > I tried a query which has a pattern: > > > > > > column IN (1212 + 1, 1212 + 2, 1212) > > > > > > For the tuple, Calcite makes a plan like > > > > > > UnionAll(all=[true]) > > > UnionAll(all=[true]) > > > Project(EXPR$0=[+(1212, 1)]) > > > Values > > > Project(EXPR$0=[+(1212, 2)]) > > > Values > > > Values > > > > > > And I found one surprising thing. At planning time, ValuesPrel has the > > > correct RelRecordType > > > > > > However, at execution, the schema of the recordbatch from scanning > Values > > > is [`ZERO`(BIGINT: OPTIONAL), `*`(BIGINT: OPTIONAL)]. > > > > > > I cannot make sense out of the second column (i.e., *). Does that serve > > > special purpose? Or is it a bug which we should try to remove? Its > > > existence causes some issues for UNION ALL. > > > > > >
