Sorry for the delay on this. I opened https://issues.apache.org/jira/browse/CALCITE-1668
Kevin Risden On Mon, Feb 20, 2017 at 2:08 PM, Julian Hyde <[email protected]> wrote: > 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 <[email protected]> > 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 <[email protected]> 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 <[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 > >> > >> > >
