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:29:41 GMT
It looks like the issue is:

writeListDataIfTyped and writeMapDataIfTyped don't update atLeastOneWrite
to true if they write a value.  As such, our code is thinking that we
haven't added any columns so we add a * column.

On Sun, May 10, 2015 at 4:25 PM, Jacques Nadeau <jacques@apache.org> wrote:

> 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