Eliminate redundant predicate evaluation

[GoogleCodeExporter]

What steps will reproduce the problem?

drop dataverse test if exists;
create dataverse test;
use dataverse test;

create type foo as closed {
   id: int32,
   str: string,
   loc: point
} 

create dataset fooDS(foo) primary key id;

for $x in dataset fooDS
where $x.id=$x.id and
contains($x.str,$x.str) and
spatial-intersect($x.loc,$x.loc)
return $x

The aforementioned query produces the following plan:
distribute result [%0->$$0]
-- DISTRIBUTE_RESULT  |PARTITIONED|
  exchange 
  -- ONE_TO_ONE_EXCHANGE  |PARTITIONED|
    project ([$$0])
    -- STREAM_PROJECT  |PARTITIONED|
      select (function-call: algebricks:and, Args:[function-call: asterix:spatial-intersect, Args:[%0->$$12, %0->$$12], function-call: asterix:contains, Args:[%0->$$13, %0->$$13], function-call: algebricks:eq, Args:[%0->$$15, %0->$$15]])
      -- STREAM_SELECT  |PARTITIONED|
        assign [$$13, $$12] <- [function-call: asterix:field-access-by-index, Args:[%0->$$0, AInt32: {1}], function-call: asterix:field-access-by-index, Args:[%0->$$0, AInt32: {2}]]
        -- ASSIGN  |PARTITIONED|
          exchange 
          -- ONE_TO_ONE_EXCHANGE  |PARTITIONED|
            data-scan []<-[$$15, $$0] <- test:fooDS
            -- DATASOURCE_SCAN  |PARTITIONED|
              exchange 
              -- ONE_TO_ONE_EXCHANGE  |PARTITIONED|
                empty-tuple-source
                -- EMPTY_TUPLE_SOURCE  |PARTITIONED|

There is no real reason in evaluating predicates, since all of them are 
identical to ABoolean{true}

Original issue reported on code.google.com by ildar.absalyamov on 12 Nov 2014 at 11:13

• Blocking: #576

[GoogleCodeExporter]

Original comment by ildar.absalyamov on 12 Nov 2014 at 11:13

• Now blocking: #576

[GoogleCodeExporter]

Two thoughts:
1. This is probably not our biggest bug - in fact it's not a bug, it's a 
feature request.  Just curious why it got filed?
2. Someone needs to think carefully about nulls to make sure it's really 
redundant.  (I'm not entirely convinced that such a predicate can be correctly 
removed, but maybe so...)

Original comment by dtab...@gmail.com on 13 Nov 2014 at 6:09

[GoogleCodeExporter]

1. I was not claiming that's a bug, that's why it was filed as an Enhancement. 
:-)
The reason this was brought up by issue 576. It was not clear to me why there 
should be an R-tree lookup at all.
2. I agree in case of the nullable attributes predicate might not be evaluated 
to True, but what is the case when $x.id!=$x.id?

Original comment by ildar.absalyamov on 13 Nov 2014 at 6:52

[GoogleCodeExporter]

I see that categorization now; cool.
Give it a try, but I suspect both the = and != cases will evaluate to unknown 
rather than true or false, if I remember right. (In the final where-based 
output, only the true survive in the end - the false and the unknown are 
filtered.)

Original comment by dtab...@gmail.com on 13 Nov 2014 at 6:59

[GoogleCodeExporter]

OK, general case might not work in this case. What if there is an explicit not 
null check?

Original comment by ildar.absalyamov on 13 Nov 2014 at 7:32