You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@asterixdb.apache.org by "Ildar Absalyamov (Code Review)" <do...@asterixdb.incubator.apache.org> on 2015/11/06 19:05:58 UTC

Change in asterixdb[master]: Equivalence induced operations and the testCases: exchange o...

Ildar Absalyamov has posted comments on this change.

Change subject: Equivalence induced operations and the testCases: exchange optimization for lookup and delete when the search condition is merely composed of the single primary key.
......................................................................


Patch Set 9: Code-Review-1

(1 comment)

The change indeed overlaps my patch. It solves the same problem, but I believe does that on the wrong level of abstraction: physical rather then logical. It is true that partitioning scheme (hash or one-to-one) is dictated by physical properties, but the real why hash exchange is picked is suboptimal logical plan. Look at the plan for issue849:
commit
-- COMMIT  |PARTITIONED|
  project ([$$3])
  -- STREAM_PROJECT  |PARTITIONED|
    exchange 
    -- ONE_TO_ONE_EXCHANGE  |PARTITIONED|
      insert %0->$$4 into test:s partitioned by [%0->$$3]
      -- INSERT  |PARTITIONED|
        exchange 
        -- HASH_PARTITION_EXCHANGE [$$3]  |PARTITIONED|
          assign [$$3] <- [function-call: asterix:field-access-by-index, Args:[%0->$$4, AInt32: {0}]]
          -- ASSIGN  |UNPARTITIONED|
            assign [$$4] <- [function-call: asterix:cast-record, Args:[function-call: asterix:closed-record-constructor, Args:[AString: {b}, AInt64: {3}]]]
            -- ASSIGN  |UNPARTITIONED|
              empty-tuple-source
              -- EMPTY_TUPLE_SOURCE  |UNPARTITIONED|

Here $$3 essentially equals to 3 (it's constant is this tiny query, but could be produced by datascan or unnest in general case). So the optimal solution will throw away field-access-by-index & record-constructor instead of just changing repartitioning pattern

https://asterix-gerrit.ics.uci.edu/#/c/428/9/asterix-algebra/src/main/java/org/apache/asterix/optimizer/rules/PreComputePartitionIdForInsertAndDeleteRule.java
File asterix-algebra/src/main/java/org/apache/asterix/optimizer/rules/PreComputePartitionIdForInsertAndDeleteRule.java:

Line 105:  */
Can we add a comment here, describing what's the purpose of the rule, what is the plan before, what's the plan after?


-- 
To view, visit https://asterix-gerrit.ics.uci.edu/428
To unsubscribe, visit https://asterix-gerrit.ics.uci.edu/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: Iaad567eecc4c91019ecba56cca085acde34d5196
Gerrit-PatchSet: 9
Gerrit-Project: asterixdb
Gerrit-Branch: master
Gerrit-Owner: Wenhai Li <lw...@yahoo.com>
Gerrit-Reviewer: Ian Maxon <im...@apache.org>
Gerrit-Reviewer: Ildar Absalyamov <il...@gmail.com>
Gerrit-Reviewer: Jenkins <je...@fulliautomatix.ics.uci.edu>
Gerrit-Reviewer: Jianfeng Jia <ji...@gmail.com>
Gerrit-Reviewer: Steven Jacobs <sj...@ucr.edu>
Gerrit-Reviewer: Till Westmann <ti...@apache.org>
Gerrit-Reviewer: Yingyi Bu <bu...@gmail.com>
Gerrit-HasComments: Yes