shamim8888 / asterixdb

Automatically exported from code.google.com/p/asterixdb
0 stars 0 forks source link

Bad application of pushselectintojoin #891

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
Here is an application of pushselectintojoin:
select (function-call: algebricks:ge, Args:[function-call: 
asterix:field-access-by-name, Args:[%0->$$1, AString: {timestamp}], %0->$$2]) 
-- |UNPARTITIONED|
  assign [$$2] <- [ADateTime: { 2015-06-01T19:54:47.692Z }] -- |UNPARTITIONED|
    join (TRUE) -- |UNPARTITIONED|
      data-scan []<-[$$37, $$0] <- emergencyTest:NearbySheltersDuringTornadoDangerChannelSubscriptions -- |UNPARTITIONED|
        empty-tuple-source -- |UNPARTITIONED|
      select (function-call: algebricks:eq, Args:[function-call: asterix:field-access-by-name, Args:[%0->$$1, AString: {etype}], AString: {tornado}]) -- |UNPARTITIONED|
        data-scan []<-[$$38, $$1] <- emergencyTest:CHPReports -- |UNPARTITIONED|
          empty-tuple-source -- |UNPARTITIONED|

Jun 01, 2015 1:04:51 PM 
edu.uci.ics.hyracks.algebricks.core.rewriter.base.AbstractRuleController 
printRuleApplication
FINE: >>>> After plan
join (function-call: algebricks:ge, Args:[function-call: 
asterix:field-access-by-name, Args:[%0->$$1, AString: {timestamp}], %0->$$2]) 
-- |UNPARTITIONED|
  assign [$$2] <- [ADateTime: { 2015-06-01T19:54:47.692Z }] -- |UNPARTITIONED|
    data-scan []<-[$$37, $$0] <- emergencyTest:NearbySheltersDuringTornadoDangerChannelSubscriptions -- |UNPARTITIONED|
      empty-tuple-source -- |UNPARTITIONED|
  select (function-call: algebricks:eq, Args:[function-call: asterix:field-access-by-name, Args:[%0->$$1, AString: {etype}], AString: {tornado}]) -- |UNPARTITIONED|
    data-scan []<-[$$38, $$1] <- emergencyTest:CHPReports -- |UNPARTITIONED|
      empty-tuple-source -- |UNPARTITIONED|

This is a poor decision. The selection only actually depends on the right 
branch, but the assign is pushed into the left branch if it is independent of 
the two branches. This meant that the selection suddenly became dependent on 
both branches and entered the join, which produces a plan that is not conducive 
to future optimizations.

Original issue reported on code.google.com by sjaco...@ucr.edu on 2 Jun 2015 at 6:36