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 <[email protected]> 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 <[email protected] > <mailto:[email protected]>> 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 <[email protected]> >> 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
