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 02:13:41 GMT
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>
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message