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 Thu, 02 Mar 2017 20:37:37 GMT
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 <jhyde@apache.org> 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 <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message