Partitioning for deletes and inserts is wrong

[GoogleCodeExporter]

What steps will reproduce the problem?

Run the following on our demo DB:

use dataverse TinySocial;
delete $tm from dataset TweetMessages
where $tm.tweetid = "15";

What is the expected output? What do you see instead?

The optimized logical query plan is as follows - including a 
HASH_PARTITION_EXCHANGE that should be a ONE_TO_ONE_EXCHANGE.
Why???
This is a performance bug that we need to fix!
There is no need to be routing data there in the plan - and on the query side, 
we are smart enough NOT to do that when we move from secondary to primary index 
lookups (i.e., when using PKs coming from an SK lookup).

-- COMMIT  |PARTITIONED|
  project ([$$12])
  -- STREAM_PROJECT  |PARTITIONED|
    exchange 
    -- ONE_TO_ONE_EXCHANGE  |PARTITIONED|
      delete from TinySocial:TweetMessages from %0->$$4 partitioned by [%0->$$12]
      -- INSERT_DELETE  |PARTITIONED|
        exchange 
        -- ONE_TO_ONE_EXCHANGE  |PARTITIONED|
          materialize 
          -- MATERIALIZE  |PARTITIONED|
            exchange 
            -- HASH_PARTITION_EXCHANGE [$$12]  |PARTITIONED|
              assign [$$12] <- [function-call: asterix:field-access-by-index, Args:[%0->$$4, AInt32: {0}]]
              -- ASSIGN  |PARTITIONED|
                project ([$$4])
                -- STREAM_PROJECT  |PARTITIONED|
                  assign [$$4] <- [function-call: asterix:open-record-constructor, Args:[AString: {tweetid}, %0->$$14, AString: {user}, function-call: asterix:field-access-by-index, Args:[%0->$$0, AInt32: {1}], AString: {sender-location}, function-call: asterix:field-access-by-index, Args:[%0->$$0, AInt32: {2}], AString: {send-time}, function-call: asterix:field-access-by-index, Args:[%0->$$0, AInt32: {3}], AString: {referred-topics}, function-call: asterix:field-access-by-index, Args:[%0->$$0, AInt32: {4}], AString: {message-text}, function-call: asterix:field-access-by-index, Args:[%0->$$0, AInt32: {5}]]]
                  -- ASSIGN  |PARTITIONED|
                    exchange 
                    -- ONE_TO_ONE_EXCHANGE  |PARTITIONED|
                      unnest-map [$$14, $$0] <- function-call: asterix:index-search, Args:[AString: {TweetMessages}, AInt32: {0}, AString: {TinySocial}, AString: {TweetMessages}, ABoolean: {false}, ABoolean: {false}, ABoolean: {false}, AInt32: {1}, %0->$$20, AInt32: {1}, %0->$$21, TRUE, TRUE, TRUE]
                      -- BTREE_SEARCH  |PARTITIONED|
                        exchange 
                        -- ONE_TO_ONE_EXCHANGE  |PARTITIONED|
                          assign [$$20, $$21] <- [AString: {15}, AString: {15}]
                          -- ASSIGN  |PARTITIONED|
                            empty-tuple-source
                            -- EMPTY_TUPLE_SOURCE  |PARTITIONED|

Please use labels and text to provide additional information.

Original issue reported on code.google.com by dtab...@gmail.com on 23 Apr 2015 at 1:07

[GoogleCodeExporter]

@Yingyi - this is causing a problem that surfaced for Wenhai.
Can you give him some guidance on how this is occurring and how to attack it?
(Ask me if this makes too little sense...)

Original comment by dtab...@gmail.com on 23 Apr 2015 at 1:12

[GoogleCodeExporter]

Ok, sure, that makes sense.  I'll talk to Wenhai.
I guess somewhere the data property propagation doe not get right.

Original comment by buyingyi@gmail.com on 23 Apr 2015 at 3:22

[GoogleCodeExporter]

Now, fixed and run. Any suggestion?

Original comment by lwhay...@gmail.com on 10 Jul 2015 at 5:27

[GoogleCodeExporter]

Next step - review w/Yingyi?

Original comment by dtab...@gmail.com on 12 Jul 2015 at 6:08

[GoogleCodeExporter]

The asterixdb jenkins test run for this change still has some issue --- it
seems something is hanging in the recovery test.  Wenhai is investigating
that.

Best,
Yingyi

Original comment by buyingyi@gmail.com on 12 Jul 2015 at 6:16