You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@calcite.apache.org by Enrico Olivelli <eo...@gmail.com> on 2017/11/17 14:27:44 UTC
BindableTableScan is losing aliased named
Hi,
I have a ProjectableFilterableTable, it seems to me that the BindablaScan
RelNode does not keep track of column name aliases in the original
projection
Example:
Query:SELECT k1 theKey FROM tblspace1.tsql where k1 ='mykey2'
-- Logical Plan
LogicalProject(THEKEY=[$0])
LogicalFilter(condition=[=($0, 'mykey2')])
EnumerableTableScan(table=[[tblspace1, tsql]])
-- Best Plan
EnumerableInterpreter
BindableTableScan(table=[[tblspace1, tsql]], filters=[[=($0, 'mykey2')]],
projects=[[0]])
Is this correct ?
IMHO It would better to keep somethin like an EnumerableProjection which
renames the fields
Am I missing something ?
Thanks
Enrico
Re: BindableTableScan is losing aliased named
Posted by Enrico Olivelli <eo...@gmail.com>.
I solved my problem just by capturing the original rowtype after sql parser.
Thanks
Enrico
Il ven 17 nov 2017, 22:44 Enrico Olivelli <eo...@gmail.com> ha scritto:
>
>
> Il ven 17 nov 2017, 22:36 Julian Hyde <jh...@apache.org> ha scritto:
>
>> Translating to RelNode loses some metadata. When preparing a SQL
>> statement, we use the column names and types given to us by the
>> validator for use by ResultSetMetaData.
>>
>> There's a related interesting case where a column appears in ORDER BY
>> but not SELECT. For example, "SELECT x FROM t ORDER BY x, y". The
>> RelNode needs to have 2 columns but the ResultSet thinks it only has
>> one.
>>
>
> I am observing that Calcite tends to add support fields always at the
> 'right'. Is this a general behaviour or I am lucky and all the plans I am
> seeing behave this way ?
>
> I think I will try to capture field names from the SqlNodes, but this will
> be feasible if and only if the first N selected RelNodes of the physical
> plan represent the first N SqlNodes in the Select clause
>
> Enrico
>
>
>> Julian
>>
>>
>> On Fri, Nov 17, 2017 at 10:46 AM, Enrico Olivelli <eo...@gmail.com>
>> wrote:
>> > Il ven 17 nov 2017, 19:19 Julian Hyde <jh...@apache.org> ha scritto:
>> >
>> >> > IMHO It would better to keep somethin like an EnumerableProjection
>> which
>> >> > renames the fields
>> >>
>> >> I disagree. If we commit to preserving field names all kinds of
>> >> optimization are not possible.
>> >>
>> >> In Calcite RelNode world, field names are a hint to make debugging
>> >> easier but are not ultimately reliable. The reliable way to reference
>> >> fields is by position.
>> >>
>> >
>> >
>> > I understand your point Julian. In my case I want the final resultset to
>> > have knowledge of the alias requested by the user.
>> >
>> > Select a as b from table
>> >
>> > ResultSet rs = ...
>> > String col = rs.getString("b");
>> > If I am losing the alias I can't support this case.
>> > The test case from Luis is working so there is some trick I am missing
>> >
>> > Enrico
>> >
>> >
>> >> Julian
>> >>
>> >>
>> >> On Fri, Nov 17, 2017 at 9:33 AM, Enrico Olivelli <eo...@gmail.com>
>> >> wrote:
>> >> > I run the debugger on your test case.
>> >> > IMHO The BindableTableScan RelNode does not keep the original
>> aliases of
>> >> > the query.
>> >> > The test cases runs CalciteConnection, maybe there is some magic
>> during
>> >> the
>> >> > execution of the query.
>> >> > Can you provide me some insight ?
>> >> > Maybe it is better that I provide a reproducer.
>> >> > I am not using CalciteConnection but only the planner
>> >> >
>> >> > Thanks
>> >> > Enrico
>> >> >
>> >> > 2017-11-17 18:08 GMT+01:00 Enrico Olivelli <eo...@gmail.com>:
>> >> >
>> >> >> your test is working
>> >> >>
>> >> >> I will try to understand where is the problem in my code
>> >> >>
>> >> >> b.q. I am looking for a sponsor for this patch, which is a real
>> blocker
>> >> >> for me, could you pleas take a look Luis ?
>> >> >> https://github.com/apache/calcite/pull/568
>> >> >>
>> >> >> Thank you
>> >> >> Enrico
>> >> >>
>> >> >> 2017-11-17 17:45 GMT+01:00 Luis Fernando Kauer <
>> >> >> lfkauer@yahoo.com.br.invalid>:
>> >> >>
>> >> >>> Please insert the following test in ScannableTableTest and run:
>> >> >>> /** ProjectableFilterableTable project push down using alias. */
>> >> >>> @Test public void testPFPushDownWithAlias() throws Exception {
>> >> >>> final StringBuilder buf = new StringBuilder();
>> >> >>> final Table table = new BeatlesProjectableFilterableTable(buf,
>> >> true);
>> >> >>> CalciteAssert.that()
>> >> >>> .with(newSchema("s", "beatles", table))
>> >> >>> .query("select \"i\" as theKey from \"s\".\"beatles\"")
>> >> >>> .explainContains("EnumerableInterpreter\n"
>> >> >>> + " BindableTableScan(table=[[s, beatles]],
>> >> >>> projects=[[0]])\n")
>> >> >>> .returnsUnordered("THEKEY=4",
>> >> >>> "THEKEY=4",
>> >> >>> "THEKEY=6",
>> >> >>> "THEKEY=5"); }
>> >> >>> It passes for me.
>> >> >>> You'll need the updated version of this test class, because it was
>> >> >>> recently refactored.
>> >> >>> It's usually easier for other people to test the problem if you
>> create
>> >> >>> runnable test cases to show the problem. Em sexta-feira, 17 de
>> >> novembro
>> >> >>> de 2017 14:29:09 BRST, Enrico Olivelli <eo...@gmail.com>
>> escreveu:
>> >> >>>
>> >> >>> In the RowType I have 'k1' and not "thekey"
>> >> >>>
>> >> >>> Enrico
>> >> >>>
>> >> >>> 2017-11-17 17:20 GMT+01:00 Luis Fernando Kauer
>> >> >>> <lfkauer@yahoo.com.br.invalid
>> >> >>> >:
>> >> >>>
>> >> >>> > Did you execute the query?
>> >> >>> > ProjectRemoveRule removes the Project when it is "trivial".
>> Since
>> >> the
>> >> >>> > only used project was pushed to BindableTableScan, the Project
>> would
>> >> >>> only
>> >> >>> > set the alias, but that can be done in row type.
>> >> >>> > The result is correct because RowType is preserved with the
>> alias.
>> >> It
>> >> >>> > just does not show in the plan.
>> >> >>> > However, I seems that repeating a column with different aliases
>> >> >>> generates
>> >> >>> > an error:
>> >> >>> > SELECT k1 theKey, k1 theKey2 FROM tblspace1.tsql where k1
>> ='mykey2'
>> >> >>> >
>> >> >>> > Regards,
>> >> >>> > Luis Fernando
>> >> >>> >
>> >> >>> > Em sexta-feira, 17 de novembro de 2017 12:27:49 BRST, Enrico
>> >> >>> Olivelli <
>> >> >>> > eolivelli@gmail.com> escreveu:
>> >> >>> >
>> >> >>> > Hi,
>> >> >>> > I have a ProjectableFilterableTable, it seems to me that the
>> >> >>> BindablaScan
>> >> >>> > RelNode does not keep track of column name aliases in the
>> original
>> >> >>> > projection
>> >> >>> >
>> >> >>> > Example:
>> >> >>> >
>> >> >>> > Query:SELECT k1 theKey FROM tblspace1.tsql where k1 ='mykey2'
>> >> >>> >
>> >> >>> > -- Logical Plan
>> >> >>> > LogicalProject(THEKEY=[$0])
>> >> >>> > LogicalFilter(condition=[=($0, 'mykey2')])
>> >> >>> > EnumerableTableScan(table=[[tblspace1, tsql]])
>> >> >>> >
>> >> >>> > -- Best Plan
>> >> >>> > EnumerableInterpreter
>> >> >>> > BindableTableScan(table=[[tblspace1, tsql]], filters=[[=($0,
>> >> >>> > 'mykey2')]],
>> >> >>> > projects=[[0]])
>> >> >>> >
>> >> >>> > Is this correct ?
>> >> >>> > IMHO It would better to keep somethin like an
>> EnumerableProjection
>> >> which
>> >> >>> > renames the fields
>> >> >>> >
>> >> >>> > Am I missing something ?
>> >> >>> > Thanks
>> >> >>> > Enrico
>> >> >>> >
>> >> >>> >
>> >> >>>
>> >> >>>
>> >> >>
>> >> >>
>> >>
>> > --
>> >
>> >
>> > -- Enrico Olivelli
>>
> --
>
>
> -- Enrico Olivelli
>
--
-- Enrico Olivelli
Re: BindableTableScan is losing aliased named
Posted by Enrico Olivelli <eo...@gmail.com>.
Il ven 17 nov 2017, 22:36 Julian Hyde <jh...@apache.org> ha scritto:
> Translating to RelNode loses some metadata. When preparing a SQL
> statement, we use the column names and types given to us by the
> validator for use by ResultSetMetaData.
>
> There's a related interesting case where a column appears in ORDER BY
> but not SELECT. For example, "SELECT x FROM t ORDER BY x, y". The
> RelNode needs to have 2 columns but the ResultSet thinks it only has
> one.
>
I am observing that Calcite tends to add support fields always at the
'right'. Is this a general behaviour or I am lucky and all the plans I am
seeing behave this way ?
I think I will try to capture field names from the SqlNodes, but this will
be feasible if and only if the first N selected RelNodes of the physical
plan represent the first N SqlNodes in the Select clause
Enrico
> Julian
>
>
> On Fri, Nov 17, 2017 at 10:46 AM, Enrico Olivelli <eo...@gmail.com>
> wrote:
> > Il ven 17 nov 2017, 19:19 Julian Hyde <jh...@apache.org> ha scritto:
> >
> >> > IMHO It would better to keep somethin like an EnumerableProjection
> which
> >> > renames the fields
> >>
> >> I disagree. If we commit to preserving field names all kinds of
> >> optimization are not possible.
> >>
> >> In Calcite RelNode world, field names are a hint to make debugging
> >> easier but are not ultimately reliable. The reliable way to reference
> >> fields is by position.
> >>
> >
> >
> > I understand your point Julian. In my case I want the final resultset to
> > have knowledge of the alias requested by the user.
> >
> > Select a as b from table
> >
> > ResultSet rs = ...
> > String col = rs.getString("b");
> > If I am losing the alias I can't support this case.
> > The test case from Luis is working so there is some trick I am missing
> >
> > Enrico
> >
> >
> >> Julian
> >>
> >>
> >> On Fri, Nov 17, 2017 at 9:33 AM, Enrico Olivelli <eo...@gmail.com>
> >> wrote:
> >> > I run the debugger on your test case.
> >> > IMHO The BindableTableScan RelNode does not keep the original aliases
> of
> >> > the query.
> >> > The test cases runs CalciteConnection, maybe there is some magic
> during
> >> the
> >> > execution of the query.
> >> > Can you provide me some insight ?
> >> > Maybe it is better that I provide a reproducer.
> >> > I am not using CalciteConnection but only the planner
> >> >
> >> > Thanks
> >> > Enrico
> >> >
> >> > 2017-11-17 18:08 GMT+01:00 Enrico Olivelli <eo...@gmail.com>:
> >> >
> >> >> your test is working
> >> >>
> >> >> I will try to understand where is the problem in my code
> >> >>
> >> >> b.q. I am looking for a sponsor for this patch, which is a real
> blocker
> >> >> for me, could you pleas take a look Luis ?
> >> >> https://github.com/apache/calcite/pull/568
> >> >>
> >> >> Thank you
> >> >> Enrico
> >> >>
> >> >> 2017-11-17 17:45 GMT+01:00 Luis Fernando Kauer <
> >> >> lfkauer@yahoo.com.br.invalid>:
> >> >>
> >> >>> Please insert the following test in ScannableTableTest and run:
> >> >>> /** ProjectableFilterableTable project push down using alias. */
> >> >>> @Test public void testPFPushDownWithAlias() throws Exception {
> >> >>> final StringBuilder buf = new StringBuilder();
> >> >>> final Table table = new BeatlesProjectableFilterableTable(buf,
> >> true);
> >> >>> CalciteAssert.that()
> >> >>> .with(newSchema("s", "beatles", table))
> >> >>> .query("select \"i\" as theKey from \"s\".\"beatles\"")
> >> >>> .explainContains("EnumerableInterpreter\n"
> >> >>> + " BindableTableScan(table=[[s, beatles]],
> >> >>> projects=[[0]])\n")
> >> >>> .returnsUnordered("THEKEY=4",
> >> >>> "THEKEY=4",
> >> >>> "THEKEY=6",
> >> >>> "THEKEY=5"); }
> >> >>> It passes for me.
> >> >>> You'll need the updated version of this test class, because it was
> >> >>> recently refactored.
> >> >>> It's usually easier for other people to test the problem if you
> create
> >> >>> runnable test cases to show the problem. Em sexta-feira, 17 de
> >> novembro
> >> >>> de 2017 14:29:09 BRST, Enrico Olivelli <eo...@gmail.com>
> escreveu:
> >> >>>
> >> >>> In the RowType I have 'k1' and not "thekey"
> >> >>>
> >> >>> Enrico
> >> >>>
> >> >>> 2017-11-17 17:20 GMT+01:00 Luis Fernando Kauer
> >> >>> <lfkauer@yahoo.com.br.invalid
> >> >>> >:
> >> >>>
> >> >>> > Did you execute the query?
> >> >>> > ProjectRemoveRule removes the Project when it is "trivial". Since
> >> the
> >> >>> > only used project was pushed to BindableTableScan, the Project
> would
> >> >>> only
> >> >>> > set the alias, but that can be done in row type.
> >> >>> > The result is correct because RowType is preserved with the alias.
> >> It
> >> >>> > just does not show in the plan.
> >> >>> > However, I seems that repeating a column with different aliases
> >> >>> generates
> >> >>> > an error:
> >> >>> > SELECT k1 theKey, k1 theKey2 FROM tblspace1.tsql where k1
> ='mykey2'
> >> >>> >
> >> >>> > Regards,
> >> >>> > Luis Fernando
> >> >>> >
> >> >>> > Em sexta-feira, 17 de novembro de 2017 12:27:49 BRST, Enrico
> >> >>> Olivelli <
> >> >>> > eolivelli@gmail.com> escreveu:
> >> >>> >
> >> >>> > Hi,
> >> >>> > I have a ProjectableFilterableTable, it seems to me that the
> >> >>> BindablaScan
> >> >>> > RelNode does not keep track of column name aliases in the original
> >> >>> > projection
> >> >>> >
> >> >>> > Example:
> >> >>> >
> >> >>> > Query:SELECT k1 theKey FROM tblspace1.tsql where k1 ='mykey2'
> >> >>> >
> >> >>> > -- Logical Plan
> >> >>> > LogicalProject(THEKEY=[$0])
> >> >>> > LogicalFilter(condition=[=($0, 'mykey2')])
> >> >>> > EnumerableTableScan(table=[[tblspace1, tsql]])
> >> >>> >
> >> >>> > -- Best Plan
> >> >>> > EnumerableInterpreter
> >> >>> > BindableTableScan(table=[[tblspace1, tsql]], filters=[[=($0,
> >> >>> > 'mykey2')]],
> >> >>> > projects=[[0]])
> >> >>> >
> >> >>> > Is this correct ?
> >> >>> > IMHO It would better to keep somethin like an EnumerableProjection
> >> which
> >> >>> > renames the fields
> >> >>> >
> >> >>> > Am I missing something ?
> >> >>> > Thanks
> >> >>> > Enrico
> >> >>> >
> >> >>> >
> >> >>>
> >> >>>
> >> >>
> >> >>
> >>
> > --
> >
> >
> > -- Enrico Olivelli
>
--
-- Enrico Olivelli
Re: BindableTableScan is losing aliased named
Posted by Julian Hyde <jh...@apache.org>.
Translating to RelNode loses some metadata. When preparing a SQL
statement, we use the column names and types given to us by the
validator for use by ResultSetMetaData.
There's a related interesting case where a column appears in ORDER BY
but not SELECT. For example, "SELECT x FROM t ORDER BY x, y". The
RelNode needs to have 2 columns but the ResultSet thinks it only has
one.
Julian
On Fri, Nov 17, 2017 at 10:46 AM, Enrico Olivelli <eo...@gmail.com> wrote:
> Il ven 17 nov 2017, 19:19 Julian Hyde <jh...@apache.org> ha scritto:
>
>> > IMHO It would better to keep somethin like an EnumerableProjection which
>> > renames the fields
>>
>> I disagree. If we commit to preserving field names all kinds of
>> optimization are not possible.
>>
>> In Calcite RelNode world, field names are a hint to make debugging
>> easier but are not ultimately reliable. The reliable way to reference
>> fields is by position.
>>
>
>
> I understand your point Julian. In my case I want the final resultset to
> have knowledge of the alias requested by the user.
>
> Select a as b from table
>
> ResultSet rs = ...
> String col = rs.getString("b");
> If I am losing the alias I can't support this case.
> The test case from Luis is working so there is some trick I am missing
>
> Enrico
>
>
>> Julian
>>
>>
>> On Fri, Nov 17, 2017 at 9:33 AM, Enrico Olivelli <eo...@gmail.com>
>> wrote:
>> > I run the debugger on your test case.
>> > IMHO The BindableTableScan RelNode does not keep the original aliases of
>> > the query.
>> > The test cases runs CalciteConnection, maybe there is some magic during
>> the
>> > execution of the query.
>> > Can you provide me some insight ?
>> > Maybe it is better that I provide a reproducer.
>> > I am not using CalciteConnection but only the planner
>> >
>> > Thanks
>> > Enrico
>> >
>> > 2017-11-17 18:08 GMT+01:00 Enrico Olivelli <eo...@gmail.com>:
>> >
>> >> your test is working
>> >>
>> >> I will try to understand where is the problem in my code
>> >>
>> >> b.q. I am looking for a sponsor for this patch, which is a real blocker
>> >> for me, could you pleas take a look Luis ?
>> >> https://github.com/apache/calcite/pull/568
>> >>
>> >> Thank you
>> >> Enrico
>> >>
>> >> 2017-11-17 17:45 GMT+01:00 Luis Fernando Kauer <
>> >> lfkauer@yahoo.com.br.invalid>:
>> >>
>> >>> Please insert the following test in ScannableTableTest and run:
>> >>> /** ProjectableFilterableTable project push down using alias. */
>> >>> @Test public void testPFPushDownWithAlias() throws Exception {
>> >>> final StringBuilder buf = new StringBuilder();
>> >>> final Table table = new BeatlesProjectableFilterableTable(buf,
>> true);
>> >>> CalciteAssert.that()
>> >>> .with(newSchema("s", "beatles", table))
>> >>> .query("select \"i\" as theKey from \"s\".\"beatles\"")
>> >>> .explainContains("EnumerableInterpreter\n"
>> >>> + " BindableTableScan(table=[[s, beatles]],
>> >>> projects=[[0]])\n")
>> >>> .returnsUnordered("THEKEY=4",
>> >>> "THEKEY=4",
>> >>> "THEKEY=6",
>> >>> "THEKEY=5"); }
>> >>> It passes for me.
>> >>> You'll need the updated version of this test class, because it was
>> >>> recently refactored.
>> >>> It's usually easier for other people to test the problem if you create
>> >>> runnable test cases to show the problem. Em sexta-feira, 17 de
>> novembro
>> >>> de 2017 14:29:09 BRST, Enrico Olivelli <eo...@gmail.com> escreveu:
>> >>>
>> >>> In the RowType I have 'k1' and not "thekey"
>> >>>
>> >>> Enrico
>> >>>
>> >>> 2017-11-17 17:20 GMT+01:00 Luis Fernando Kauer
>> >>> <lfkauer@yahoo.com.br.invalid
>> >>> >:
>> >>>
>> >>> > Did you execute the query?
>> >>> > ProjectRemoveRule removes the Project when it is "trivial". Since
>> the
>> >>> > only used project was pushed to BindableTableScan, the Project would
>> >>> only
>> >>> > set the alias, but that can be done in row type.
>> >>> > The result is correct because RowType is preserved with the alias.
>> It
>> >>> > just does not show in the plan.
>> >>> > However, I seems that repeating a column with different aliases
>> >>> generates
>> >>> > an error:
>> >>> > SELECT k1 theKey, k1 theKey2 FROM tblspace1.tsql where k1 ='mykey2'
>> >>> >
>> >>> > Regards,
>> >>> > Luis Fernando
>> >>> >
>> >>> > Em sexta-feira, 17 de novembro de 2017 12:27:49 BRST, Enrico
>> >>> Olivelli <
>> >>> > eolivelli@gmail.com> escreveu:
>> >>> >
>> >>> > Hi,
>> >>> > I have a ProjectableFilterableTable, it seems to me that the
>> >>> BindablaScan
>> >>> > RelNode does not keep track of column name aliases in the original
>> >>> > projection
>> >>> >
>> >>> > Example:
>> >>> >
>> >>> > Query:SELECT k1 theKey FROM tblspace1.tsql where k1 ='mykey2'
>> >>> >
>> >>> > -- Logical Plan
>> >>> > LogicalProject(THEKEY=[$0])
>> >>> > LogicalFilter(condition=[=($0, 'mykey2')])
>> >>> > EnumerableTableScan(table=[[tblspace1, tsql]])
>> >>> >
>> >>> > -- Best Plan
>> >>> > EnumerableInterpreter
>> >>> > BindableTableScan(table=[[tblspace1, tsql]], filters=[[=($0,
>> >>> > 'mykey2')]],
>> >>> > projects=[[0]])
>> >>> >
>> >>> > Is this correct ?
>> >>> > IMHO It would better to keep somethin like an EnumerableProjection
>> which
>> >>> > renames the fields
>> >>> >
>> >>> > Am I missing something ?
>> >>> > Thanks
>> >>> > Enrico
>> >>> >
>> >>> >
>> >>>
>> >>>
>> >>
>> >>
>>
> --
>
>
> -- Enrico Olivelli
Re: BindableTableScan is losing aliased named
Posted by Enrico Olivelli <eo...@gmail.com>.
Il ven 17 nov 2017, 19:19 Julian Hyde <jh...@apache.org> ha scritto:
> > IMHO It would better to keep somethin like an EnumerableProjection which
> > renames the fields
>
> I disagree. If we commit to preserving field names all kinds of
> optimization are not possible.
>
> In Calcite RelNode world, field names are a hint to make debugging
> easier but are not ultimately reliable. The reliable way to reference
> fields is by position.
>
I understand your point Julian. In my case I want the final resultset to
have knowledge of the alias requested by the user.
Select a as b from table
ResultSet rs = ...
String col = rs.getString("b");
If I am losing the alias I can't support this case.
The test case from Luis is working so there is some trick I am missing
Enrico
> Julian
>
>
> On Fri, Nov 17, 2017 at 9:33 AM, Enrico Olivelli <eo...@gmail.com>
> wrote:
> > I run the debugger on your test case.
> > IMHO The BindableTableScan RelNode does not keep the original aliases of
> > the query.
> > The test cases runs CalciteConnection, maybe there is some magic during
> the
> > execution of the query.
> > Can you provide me some insight ?
> > Maybe it is better that I provide a reproducer.
> > I am not using CalciteConnection but only the planner
> >
> > Thanks
> > Enrico
> >
> > 2017-11-17 18:08 GMT+01:00 Enrico Olivelli <eo...@gmail.com>:
> >
> >> your test is working
> >>
> >> I will try to understand where is the problem in my code
> >>
> >> b.q. I am looking for a sponsor for this patch, which is a real blocker
> >> for me, could you pleas take a look Luis ?
> >> https://github.com/apache/calcite/pull/568
> >>
> >> Thank you
> >> Enrico
> >>
> >> 2017-11-17 17:45 GMT+01:00 Luis Fernando Kauer <
> >> lfkauer@yahoo.com.br.invalid>:
> >>
> >>> Please insert the following test in ScannableTableTest and run:
> >>> /** ProjectableFilterableTable project push down using alias. */
> >>> @Test public void testPFPushDownWithAlias() throws Exception {
> >>> final StringBuilder buf = new StringBuilder();
> >>> final Table table = new BeatlesProjectableFilterableTable(buf,
> true);
> >>> CalciteAssert.that()
> >>> .with(newSchema("s", "beatles", table))
> >>> .query("select \"i\" as theKey from \"s\".\"beatles\"")
> >>> .explainContains("EnumerableInterpreter\n"
> >>> + " BindableTableScan(table=[[s, beatles]],
> >>> projects=[[0]])\n")
> >>> .returnsUnordered("THEKEY=4",
> >>> "THEKEY=4",
> >>> "THEKEY=6",
> >>> "THEKEY=5"); }
> >>> It passes for me.
> >>> You'll need the updated version of this test class, because it was
> >>> recently refactored.
> >>> It's usually easier for other people to test the problem if you create
> >>> runnable test cases to show the problem. Em sexta-feira, 17 de
> novembro
> >>> de 2017 14:29:09 BRST, Enrico Olivelli <eo...@gmail.com> escreveu:
> >>>
> >>> In the RowType I have 'k1' and not "thekey"
> >>>
> >>> Enrico
> >>>
> >>> 2017-11-17 17:20 GMT+01:00 Luis Fernando Kauer
> >>> <lfkauer@yahoo.com.br.invalid
> >>> >:
> >>>
> >>> > Did you execute the query?
> >>> > ProjectRemoveRule removes the Project when it is "trivial". Since
> the
> >>> > only used project was pushed to BindableTableScan, the Project would
> >>> only
> >>> > set the alias, but that can be done in row type.
> >>> > The result is correct because RowType is preserved with the alias.
> It
> >>> > just does not show in the plan.
> >>> > However, I seems that repeating a column with different aliases
> >>> generates
> >>> > an error:
> >>> > SELECT k1 theKey, k1 theKey2 FROM tblspace1.tsql where k1 ='mykey2'
> >>> >
> >>> > Regards,
> >>> > Luis Fernando
> >>> >
> >>> > Em sexta-feira, 17 de novembro de 2017 12:27:49 BRST, Enrico
> >>> Olivelli <
> >>> > eolivelli@gmail.com> escreveu:
> >>> >
> >>> > Hi,
> >>> > I have a ProjectableFilterableTable, it seems to me that the
> >>> BindablaScan
> >>> > RelNode does not keep track of column name aliases in the original
> >>> > projection
> >>> >
> >>> > Example:
> >>> >
> >>> > Query:SELECT k1 theKey FROM tblspace1.tsql where k1 ='mykey2'
> >>> >
> >>> > -- Logical Plan
> >>> > LogicalProject(THEKEY=[$0])
> >>> > LogicalFilter(condition=[=($0, 'mykey2')])
> >>> > EnumerableTableScan(table=[[tblspace1, tsql]])
> >>> >
> >>> > -- Best Plan
> >>> > EnumerableInterpreter
> >>> > BindableTableScan(table=[[tblspace1, tsql]], filters=[[=($0,
> >>> > 'mykey2')]],
> >>> > projects=[[0]])
> >>> >
> >>> > Is this correct ?
> >>> > IMHO It would better to keep somethin like an EnumerableProjection
> which
> >>> > renames the fields
> >>> >
> >>> > Am I missing something ?
> >>> > Thanks
> >>> > Enrico
> >>> >
> >>> >
> >>>
> >>>
> >>
> >>
>
--
-- Enrico Olivelli
Re: BindableTableScan is losing aliased named
Posted by Julian Hyde <jh...@apache.org>.
> IMHO It would better to keep somethin like an EnumerableProjection which
> renames the fields
I disagree. If we commit to preserving field names all kinds of
optimization are not possible.
In Calcite RelNode world, field names are a hint to make debugging
easier but are not ultimately reliable. The reliable way to reference
fields is by position.
Julian
On Fri, Nov 17, 2017 at 9:33 AM, Enrico Olivelli <eo...@gmail.com> wrote:
> I run the debugger on your test case.
> IMHO The BindableTableScan RelNode does not keep the original aliases of
> the query.
> The test cases runs CalciteConnection, maybe there is some magic during the
> execution of the query.
> Can you provide me some insight ?
> Maybe it is better that I provide a reproducer.
> I am not using CalciteConnection but only the planner
>
> Thanks
> Enrico
>
> 2017-11-17 18:08 GMT+01:00 Enrico Olivelli <eo...@gmail.com>:
>
>> your test is working
>>
>> I will try to understand where is the problem in my code
>>
>> b.q. I am looking for a sponsor for this patch, which is a real blocker
>> for me, could you pleas take a look Luis ?
>> https://github.com/apache/calcite/pull/568
>>
>> Thank you
>> Enrico
>>
>> 2017-11-17 17:45 GMT+01:00 Luis Fernando Kauer <
>> lfkauer@yahoo.com.br.invalid>:
>>
>>> Please insert the following test in ScannableTableTest and run:
>>> /** ProjectableFilterableTable project push down using alias. */
>>> @Test public void testPFPushDownWithAlias() throws Exception {
>>> final StringBuilder buf = new StringBuilder();
>>> final Table table = new BeatlesProjectableFilterableTable(buf, true);
>>> CalciteAssert.that()
>>> .with(newSchema("s", "beatles", table))
>>> .query("select \"i\" as theKey from \"s\".\"beatles\"")
>>> .explainContains("EnumerableInterpreter\n"
>>> + " BindableTableScan(table=[[s, beatles]],
>>> projects=[[0]])\n")
>>> .returnsUnordered("THEKEY=4",
>>> "THEKEY=4",
>>> "THEKEY=6",
>>> "THEKEY=5"); }
>>> It passes for me.
>>> You'll need the updated version of this test class, because it was
>>> recently refactored.
>>> It's usually easier for other people to test the problem if you create
>>> runnable test cases to show the problem. Em sexta-feira, 17 de novembro
>>> de 2017 14:29:09 BRST, Enrico Olivelli <eo...@gmail.com> escreveu:
>>>
>>> In the RowType I have 'k1' and not "thekey"
>>>
>>> Enrico
>>>
>>> 2017-11-17 17:20 GMT+01:00 Luis Fernando Kauer
>>> <lfkauer@yahoo.com.br.invalid
>>> >:
>>>
>>> > Did you execute the query?
>>> > ProjectRemoveRule removes the Project when it is "trivial". Since the
>>> > only used project was pushed to BindableTableScan, the Project would
>>> only
>>> > set the alias, but that can be done in row type.
>>> > The result is correct because RowType is preserved with the alias. It
>>> > just does not show in the plan.
>>> > However, I seems that repeating a column with different aliases
>>> generates
>>> > an error:
>>> > SELECT k1 theKey, k1 theKey2 FROM tblspace1.tsql where k1 ='mykey2'
>>> >
>>> > Regards,
>>> > Luis Fernando
>>> >
>>> > Em sexta-feira, 17 de novembro de 2017 12:27:49 BRST, Enrico
>>> Olivelli <
>>> > eolivelli@gmail.com> escreveu:
>>> >
>>> > Hi,
>>> > I have a ProjectableFilterableTable, it seems to me that the
>>> BindablaScan
>>> > RelNode does not keep track of column name aliases in the original
>>> > projection
>>> >
>>> > Example:
>>> >
>>> > Query:SELECT k1 theKey FROM tblspace1.tsql where k1 ='mykey2'
>>> >
>>> > -- Logical Plan
>>> > LogicalProject(THEKEY=[$0])
>>> > LogicalFilter(condition=[=($0, 'mykey2')])
>>> > EnumerableTableScan(table=[[tblspace1, tsql]])
>>> >
>>> > -- Best Plan
>>> > EnumerableInterpreter
>>> > BindableTableScan(table=[[tblspace1, tsql]], filters=[[=($0,
>>> > 'mykey2')]],
>>> > projects=[[0]])
>>> >
>>> > Is this correct ?
>>> > IMHO It would better to keep somethin like an EnumerableProjection which
>>> > renames the fields
>>> >
>>> > Am I missing something ?
>>> > Thanks
>>> > Enrico
>>> >
>>> >
>>>
>>>
>>
>>
Re: BindableTableScan is losing aliased named
Posted by Enrico Olivelli <eo...@gmail.com>.
I run the debugger on your test case.
IMHO The BindableTableScan RelNode does not keep the original aliases of
the query.
The test cases runs CalciteConnection, maybe there is some magic during the
execution of the query.
Can you provide me some insight ?
Maybe it is better that I provide a reproducer.
I am not using CalciteConnection but only the planner
Thanks
Enrico
2017-11-17 18:08 GMT+01:00 Enrico Olivelli <eo...@gmail.com>:
> your test is working
>
> I will try to understand where is the problem in my code
>
> b.q. I am looking for a sponsor for this patch, which is a real blocker
> for me, could you pleas take a look Luis ?
> https://github.com/apache/calcite/pull/568
>
> Thank you
> Enrico
>
> 2017-11-17 17:45 GMT+01:00 Luis Fernando Kauer <
> lfkauer@yahoo.com.br.invalid>:
>
>> Please insert the following test in ScannableTableTest and run:
>> /** ProjectableFilterableTable project push down using alias. */
>> @Test public void testPFPushDownWithAlias() throws Exception {
>> final StringBuilder buf = new StringBuilder();
>> final Table table = new BeatlesProjectableFilterableTable(buf, true);
>> CalciteAssert.that()
>> .with(newSchema("s", "beatles", table))
>> .query("select \"i\" as theKey from \"s\".\"beatles\"")
>> .explainContains("EnumerableInterpreter\n"
>> + " BindableTableScan(table=[[s, beatles]],
>> projects=[[0]])\n")
>> .returnsUnordered("THEKEY=4",
>> "THEKEY=4",
>> "THEKEY=6",
>> "THEKEY=5"); }
>> It passes for me.
>> You'll need the updated version of this test class, because it was
>> recently refactored.
>> It's usually easier for other people to test the problem if you create
>> runnable test cases to show the problem. Em sexta-feira, 17 de novembro
>> de 2017 14:29:09 BRST, Enrico Olivelli <eo...@gmail.com> escreveu:
>>
>> In the RowType I have 'k1' and not "thekey"
>>
>> Enrico
>>
>> 2017-11-17 17:20 GMT+01:00 Luis Fernando Kauer
>> <lfkauer@yahoo.com.br.invalid
>> >:
>>
>> > Did you execute the query?
>> > ProjectRemoveRule removes the Project when it is "trivial". Since the
>> > only used project was pushed to BindableTableScan, the Project would
>> only
>> > set the alias, but that can be done in row type.
>> > The result is correct because RowType is preserved with the alias. It
>> > just does not show in the plan.
>> > However, I seems that repeating a column with different aliases
>> generates
>> > an error:
>> > SELECT k1 theKey, k1 theKey2 FROM tblspace1.tsql where k1 ='mykey2'
>> >
>> > Regards,
>> > Luis Fernando
>> >
>> > Em sexta-feira, 17 de novembro de 2017 12:27:49 BRST, Enrico
>> Olivelli <
>> > eolivelli@gmail.com> escreveu:
>> >
>> > Hi,
>> > I have a ProjectableFilterableTable, it seems to me that the
>> BindablaScan
>> > RelNode does not keep track of column name aliases in the original
>> > projection
>> >
>> > Example:
>> >
>> > Query:SELECT k1 theKey FROM tblspace1.tsql where k1 ='mykey2'
>> >
>> > -- Logical Plan
>> > LogicalProject(THEKEY=[$0])
>> > LogicalFilter(condition=[=($0, 'mykey2')])
>> > EnumerableTableScan(table=[[tblspace1, tsql]])
>> >
>> > -- Best Plan
>> > EnumerableInterpreter
>> > BindableTableScan(table=[[tblspace1, tsql]], filters=[[=($0,
>> > 'mykey2')]],
>> > projects=[[0]])
>> >
>> > Is this correct ?
>> > IMHO It would better to keep somethin like an EnumerableProjection which
>> > renames the fields
>> >
>> > Am I missing something ?
>> > Thanks
>> > Enrico
>> >
>> >
>>
>>
>
>
Re: BindableTableScan is losing aliased named
Posted by Enrico Olivelli <eo...@gmail.com>.
your test is working
I will try to understand where is the problem in my code
b.q. I am looking for a sponsor for this patch, which is a real blocker for
me, could you pleas take a look Luis ?
https://github.com/apache/calcite/pull/568
Thank you
Enrico
2017-11-17 17:45 GMT+01:00 Luis Fernando Kauer <lfkauer@yahoo.com.br.invalid
>:
> Please insert the following test in ScannableTableTest and run:
> /** ProjectableFilterableTable project push down using alias. */
> @Test public void testPFPushDownWithAlias() throws Exception {
> final StringBuilder buf = new StringBuilder();
> final Table table = new BeatlesProjectableFilterableTable(buf, true);
> CalciteAssert.that()
> .with(newSchema("s", "beatles", table))
> .query("select \"i\" as theKey from \"s\".\"beatles\"")
> .explainContains("EnumerableInterpreter\n"
> + " BindableTableScan(table=[[s, beatles]],
> projects=[[0]])\n")
> .returnsUnordered("THEKEY=4",
> "THEKEY=4",
> "THEKEY=6",
> "THEKEY=5"); }
> It passes for me.
> You'll need the updated version of this test class, because it was
> recently refactored.
> It's usually easier for other people to test the problem if you create
> runnable test cases to show the problem. Em sexta-feira, 17 de novembro
> de 2017 14:29:09 BRST, Enrico Olivelli <eo...@gmail.com> escreveu:
>
> In the RowType I have 'k1' and not "thekey"
>
> Enrico
>
> 2017-11-17 17:20 GMT+01:00 Luis Fernando Kauer
> <lfkauer@yahoo.com.br.invalid
> >:
>
> > Did you execute the query?
> > ProjectRemoveRule removes the Project when it is "trivial". Since the
> > only used project was pushed to BindableTableScan, the Project would only
> > set the alias, but that can be done in row type.
> > The result is correct because RowType is preserved with the alias. It
> > just does not show in the plan.
> > However, I seems that repeating a column with different aliases generates
> > an error:
> > SELECT k1 theKey, k1 theKey2 FROM tblspace1.tsql where k1 ='mykey2'
> >
> > Regards,
> > Luis Fernando
> >
> > Em sexta-feira, 17 de novembro de 2017 12:27:49 BRST, Enrico Olivelli
> <
> > eolivelli@gmail.com> escreveu:
> >
> > Hi,
> > I have a ProjectableFilterableTable, it seems to me that the BindablaScan
> > RelNode does not keep track of column name aliases in the original
> > projection
> >
> > Example:
> >
> > Query:SELECT k1 theKey FROM tblspace1.tsql where k1 ='mykey2'
> >
> > -- Logical Plan
> > LogicalProject(THEKEY=[$0])
> > LogicalFilter(condition=[=($0, 'mykey2')])
> > EnumerableTableScan(table=[[tblspace1, tsql]])
> >
> > -- Best Plan
> > EnumerableInterpreter
> > BindableTableScan(table=[[tblspace1, tsql]], filters=[[=($0,
> > 'mykey2')]],
> > projects=[[0]])
> >
> > Is this correct ?
> > IMHO It would better to keep somethin like an EnumerableProjection which
> > renames the fields
> >
> > Am I missing something ?
> > Thanks
> > Enrico
> >
> >
>
>
Re: BindableTableScan is losing aliased named
Posted by Luis Fernando Kauer <lf...@yahoo.com.br.INVALID>.
Please insert the following test in ScannableTableTest and run:
/** ProjectableFilterableTable project push down using alias. */
@Test public void testPFPushDownWithAlias() throws Exception {
final StringBuilder buf = new StringBuilder();
final Table table = new BeatlesProjectableFilterableTable(buf, true);
CalciteAssert.that()
.with(newSchema("s", "beatles", table))
.query("select \"i\" as theKey from \"s\".\"beatles\"")
.explainContains("EnumerableInterpreter\n"
+ " BindableTableScan(table=[[s, beatles]], projects=[[0]])\n")
.returnsUnordered("THEKEY=4",
"THEKEY=4",
"THEKEY=6",
"THEKEY=5"); }
It passes for me.
You'll need the updated version of this test class, because it was recently refactored.
It's usually easier for other people to test the problem if you create runnable test cases to show the problem. Em sexta-feira, 17 de novembro de 2017 14:29:09 BRST, Enrico Olivelli <eo...@gmail.com> escreveu:
In the RowType I have 'k1' and not "thekey"
Enrico
2017-11-17 17:20 GMT+01:00 Luis Fernando Kauer <lfkauer@yahoo.com.br.invalid
>:
> Did you execute the query?
> ProjectRemoveRule removes the Project when it is "trivial". Since the
> only used project was pushed to BindableTableScan, the Project would only
> set the alias, but that can be done in row type.
> The result is correct because RowType is preserved with the alias. It
> just does not show in the plan.
> However, I seems that repeating a column with different aliases generates
> an error:
> SELECT k1 theKey, k1 theKey2 FROM tblspace1.tsql where k1 ='mykey2'
>
> Regards,
> Luis Fernando
>
> Em sexta-feira, 17 de novembro de 2017 12:27:49 BRST, Enrico Olivelli <
> eolivelli@gmail.com> escreveu:
>
> Hi,
> I have a ProjectableFilterableTable, it seems to me that the BindablaScan
> RelNode does not keep track of column name aliases in the original
> projection
>
> Example:
>
> Query:SELECT k1 theKey FROM tblspace1.tsql where k1 ='mykey2'
>
> -- Logical Plan
> LogicalProject(THEKEY=[$0])
> LogicalFilter(condition=[=($0, 'mykey2')])
> EnumerableTableScan(table=[[tblspace1, tsql]])
>
> -- Best Plan
> EnumerableInterpreter
> BindableTableScan(table=[[tblspace1, tsql]], filters=[[=($0,
> 'mykey2')]],
> projects=[[0]])
>
> Is this correct ?
> IMHO It would better to keep somethin like an EnumerableProjection which
> renames the fields
>
> Am I missing something ?
> Thanks
> Enrico
>
>
Re: BindableTableScan is losing aliased named
Posted by Enrico Olivelli <eo...@gmail.com>.
In the RowType I have 'k1' and not "thekey"
Enrico
2017-11-17 17:20 GMT+01:00 Luis Fernando Kauer <lfkauer@yahoo.com.br.invalid
>:
> Did you execute the query?
> ProjectRemoveRule removes the Project when it is "trivial". Since the
> only used project was pushed to BindableTableScan, the Project would only
> set the alias, but that can be done in row type.
> The result is correct because RowType is preserved with the alias. It
> just does not show in the plan.
> However, I seems that repeating a column with different aliases generates
> an error:
> SELECT k1 theKey, k1 theKey2 FROM tblspace1.tsql where k1 ='mykey2'
>
> Regards,
> Luis Fernando
>
> Em sexta-feira, 17 de novembro de 2017 12:27:49 BRST, Enrico Olivelli <
> eolivelli@gmail.com> escreveu:
>
> Hi,
> I have a ProjectableFilterableTable, it seems to me that the BindablaScan
> RelNode does not keep track of column name aliases in the original
> projection
>
> Example:
>
> Query:SELECT k1 theKey FROM tblspace1.tsql where k1 ='mykey2'
>
> -- Logical Plan
> LogicalProject(THEKEY=[$0])
> LogicalFilter(condition=[=($0, 'mykey2')])
> EnumerableTableScan(table=[[tblspace1, tsql]])
>
> -- Best Plan
> EnumerableInterpreter
> BindableTableScan(table=[[tblspace1, tsql]], filters=[[=($0,
> 'mykey2')]],
> projects=[[0]])
>
> Is this correct ?
> IMHO It would better to keep somethin like an EnumerableProjection which
> renames the fields
>
> Am I missing something ?
> Thanks
> Enrico
>
>
Re: BindableTableScan is losing aliased named
Posted by Luis Fernando Kauer <lf...@yahoo.com.br.INVALID>.
Did you execute the query?
ProjectRemoveRule removes the Project when it is "trivial". Since the only used project was pushed to BindableTableScan, the Project would only set the alias, but that can be done in row type.
The result is correct because RowType is preserved with the alias. It just does not show in the plan.
However, I seems that repeating a column with different aliases generates an error:
SELECT k1 theKey, k1 theKey2 FROM tblspace1.tsql where k1 ='mykey2'
Regards,
Luis Fernando
Em sexta-feira, 17 de novembro de 2017 12:27:49 BRST, Enrico Olivelli <eo...@gmail.com> escreveu:
Hi,
I have a ProjectableFilterableTable, it seems to me that the BindablaScan
RelNode does not keep track of column name aliases in the original
projection
Example:
Query:SELECT k1 theKey FROM tblspace1.tsql where k1 ='mykey2'
-- Logical Plan
LogicalProject(THEKEY=[$0])
LogicalFilter(condition=[=($0, 'mykey2')])
EnumerableTableScan(table=[[tblspace1, tsql]])
-- Best Plan
EnumerableInterpreter
BindableTableScan(table=[[tblspace1, tsql]], filters=[[=($0, 'mykey2')]],
projects=[[0]])
Is this correct ?
IMHO It would better to keep somethin like an EnumerableProjection which
renames the fields
Am I missing something ?
Thanks
Enrico