calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Hyde <jh...@apache.org>
Subject Re: Simplifying literal comparison literal
Date Mon, 20 Feb 2017 20:08:30 GMT
No worries. It’s President’s Day here in the US and none of us are supposed to be using
our laptops. :)

> On Feb 20, 2017, at 12:05 PM, Kevin Risden <compuwizard123@gmail.com> wrote:
> 
> Ok I will log a JIRA case and try to add a test. Won't be able to get to it
> till tonight when I'm back on my laptop.
> 
> Kevin Risden
> 
> On Mon, Feb 20, 2017 at 1:58 PM, Julian Hyde <jhyde@apache.org> wrote:
> 
>> I do think it’s worth considering. Can you log a JIRA case please?
>> 
>> Also, if you add a test — probably a few extra lines in RexProgramTest
>> will suffice — I will accept your PR. I think it will be efficient enough.
>> 
>> Julian
>> 
>> 
>>> On Feb 19, 2017, at 7:14 PM, Kevin Risden <compuwizard123@gmail.com>
>> wrote:
>>> 
>>> Thanks Julian. I looked in the existing rules but didn't come across the
>>> ReduceExpressionsRule.FILTER_INSTANCE. Adding that rule to the planner
>>> seems to do the same thing that I was trying to do in simplify. I don't
>>> think there is any reason to change simplify. It was just the first way
>> to
>>> found to try to work around the issue I was facing.
>>> 
>>> Would you still want a JIRA case logged since that would result in
>> multiple
>>> ways of doing the same thing?
>>> 
>>> Kevin Risden
>>> 
>>> On Sun, Feb 19, 2017 at 8:13 PM, Julian Hyde <jhyde@apache.org <mailto:
>> jhyde@apache.org>> wrote:
>>> 
>>>> We have support for this in planner rules -- I’m pretty sure that
>>>> ReduceExpressionsRule.FILTER_INSTANCE will convert ‘where 1 = 0’ to
>>>> ‘where false’, then PruneEmptyRules.FILTER_INSTANCE will make the
>> Filter
>>>> disappear altogether — but arguably it could happen in RexUtil.simplify
>>>> also.
>>>> 
>>>> The purpose of RexUtil.simplify is to simplify (only) patterns that are
>>>> commonly occurring, easy to recognize, and will produce a quick win in
>>>> terms of the size of the RelNode/RexNode tree. I don’t know yet whether
>>>> this passes that threshold. Can you log a JIRA case for this and we can
>>>> discuss further?
>>>> 
>>>> By the way, https://issues.apache.org/jira/browse/CALCITE-1638 <
>>>> https://issues.apache.org/jira/browse/CALCITE-1638 <
>> https://issues.apache.org/jira/browse/CALCITE-1638>> is related. It
>>>> changed the result of a test that was doing ‘where 1 = 1’.
>>>> 
>>>> Julian
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> On Feb 19, 2017, at 2:03 PM, Kevin Risden <compuwizard123@gmail.com>
>>>> wrote:
>>>>> 
>>>>> While working on Solr and Calcite integration, I found that there is
a
>>>> case
>>>>> where some tools issue a sql query like "where 1 = 0" just to get
>>>> metadata
>>>>> information back. Spark SQL is one of the ones that does this.
>>>>> 
>>>>> Calcite doesn't seem to optimize away the literal comparison literal
>> case
>>>>> with RexUtil.simplify. In my understanding any literal comparison
>> literal
>>>>> results in a simple TRUE/FALSE result.
>>>>> 
>>>>> I'm not sure this is valid in the general case, but I put together a
>>>> simple
>>>>> example of doing this on the RexUtil simplifyCall.
>>>>> 
>>>>> https://github.com/apache/calcite/pull/376
>>>>> 
>>>>> I would love to hear any feedback related to this. I need to run
>> through
>>>>> the full Calcite test suite, but wondering if this is even viable.
>>>>> 
>>>>> Thanks!
>>>>> 
>>>>> Kevin Risden
>> 
>> 


Mime
View raw message