3 Replies Latest reply on Feb 21, 2013 10:03 AM by shawkins

    Optimize out SELECT in the face of deterministic functions in WHERE clause

    markaddleman

      The query SELECT c FROM t WHERE c='a' AND ucase(c)='b' is gauranteed to be an empty result.  It seems like the optimizer could thread the constrained value of c through any deterministic function to know that the where clause will always be false.

       

      Is this a particularly difficult change to make to the optimizer?  If you can give me a push in the right direction, I'll try to strengthen my Teiid fu

        • 1. Re: Optimize out SELECT in the face of deterministic functions in WHERE clause
          shawkins

          There is logic in the QueryRewriter that is doing similar analysis, but just around theta predicates of column references.  It doesn't yet consider more complicated expressions.  There is also logic in RuleCopyCriteria, but it is designed more to consider copying criteria from one side of a join to another and doesn't look within predicates on the same side of the join.

           

          Steve

          • 2. Re: Optimize out SELECT in the face of deterministic functions in WHERE clause
            markaddleman

            I can write a visitor to rewrite the query as SELECT c FROM t WHERE c='a' AND ucase('a')='b'.  It appears that Teiid's optimizer handles this case well.

             

            As I read the code, I'd want to hook in this visitor somewhere inside in the QueryRewriter since that occurs early in the optimization process. 

             

            I have a question about requirements, though:  I'm pretty sure this rewriting is only valid for deterministic functions.  If that's true, then how do I determine if the function is deterministic?  It doesn't look like that information is available through the FunctionLibrary and FunctionForm data structures. 

            • 3. Re: Optimize out SELECT in the face of deterministic functions in WHERE clause
              shawkins

              > As I read the code, I'd want to hook in this visitor somewhere inside in the QueryRewriter since that occurs early in the optimization process.

               

              See the recent https://issues.jboss.org/browse/TEIID-2366 which has logic that is adaptable for this situation.  Generally the approach would be to build a map containing just the equality predicates symbol/constant pairs (which is done in the RulePushCriteria logic) and then run a EvaluatableVisitor to determine if an expression, not just a function, is something you can attempt an evaluation of using the rewriter's Evaluator.

               

              Steve