[
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)
