calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Risden <compuwizard...@gmail.com>
Subject Re: Simplifying literal comparison literal
Date Mon, 20 Feb 2017 03:14:37 GMT
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> 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> 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