[jira] [Commented] (TRAFODION-40) Compiler work to allow a conditional delete

["Hans Zeller (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TRAFODION-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14645084#comment-14645084 ] 

Hans Zeller commented on TRAFODION-40:
--------------------------------------

In the meantime I made some progress, adding the expression in the compiler and integrating with Selva's executor code. One thing I found was that if we suppress the delete, we'll get a "unique constraint violation" error in the insert, since the insert does a CheckAndPut. This makes me think of a performance optimization we could do for index maintenance of non-unique indexes: Just do a Put, not a CheckAndPut. Coding this, I'm currently running into some issues, but I also want to get feedback on whether this approach is the right one. In summary, here is the proposal:

1. If we update an index row to the same value (set x=x), suppress the delete, but continue to do the insert (we could potentially suppress the insert, too, but I want to avoid the overhead of checking another expression).

2. For inserts into non-unique indexes as part of index maintenance, change those from a CheckAndPut to a Put.

> Compiler work to allow a conditional delete
> -------------------------------------------
>
>                 Key: TRAFODION-40
>                 URL: https://issues.apache.org/jira/browse/TRAFODION-40
>             Project: Apache Trafodion
>          Issue Type: Sub-task
>            Reporter: Hans Zeller
>
> Part of TRAFODION-14.
> Selva and Suresh found that we sometimes miss index rows. This is causes if all of the following happen: a) we perform index maintenance for an update (delete of the old index row, followed by insert of the new row), b) the old and new row of the index have the same row key, i.e. we didn't change the column values in the index and c) the HBase timestamp is the same for the index delete and the update (delete and insert happen in the same millisecond).
> Selva suggested to solutions:
> 1. Determine the max. timestamp of the old row and use that timestamp for the delete. That would work (unlikely someone did an insert in a different statement in the same millisecond), but it would require reading the value before an index delete.
> 2. Add a new expression for the index delete (could also do it for the insert) that skips the delete if old and new index values match.
> We want to go with solution 2., since it has the better performance. I'm filing this JIRA for the necessary compiler work,



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)