drill-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacques Nadeau <jacq...@apache.org>
Subject Re: Schema of the Recordbatch from scanning Values seems wrong
Date Sun, 10 May 2015 23:25:23 GMT
important given its impact on expression based in queries.

On Sun, May 10, 2015 at 4:21 PM, Hsuan Yi Chu <hyichu@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 <jacques@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 <hyichu@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.
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message