[
https://issues.apache.org/jira/browse/PHOENIX-3685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15883954#comment-15883954
]
Thomas D'Silva commented on PHOENIX-3685:
-----------------------------------------
I think this happens because we always generate a delete along with the put for
an index on a mutable table. When we insert a new row (not mutate an existing
row) in IndexMaintainer.buildDeleteMutation the old value of the indexed column
is null and so a family delete is generated to delete the old row. This delete
is not required since we are inserting a new row.
{code}
public Delete buildDeleteMutation(KeyValueBuilder kvBuilder, ValueGetter
oldState, ImmutableBytesWritable dataRowKeyPtr, Collection<KeyValue>
pendingUpdates, long ts, byte[] regionStartKey, byte[] regionEndKey) throws
IOException {
byte[] indexRowKey = this.buildRowKey(oldState, dataRowKeyPtr,
regionStartKey, regionEndKey);
// Delete the entire row if any of the indexed columns changed
DeleteType deleteType = null;
if (oldState == null ||
(deleteType=getDeleteTypeOrNull(pendingUpdates)) != null ||
hasIndexedColumnChanged(oldState, pendingUpdates)) { // Deleting the entire row
byte[] emptyCF = emptyKeyValueCFPtr.copyBytesIfNecessary();
Delete delete = new Delete(indexRowKey);
for (ColumnReference ref : getCoveredColumns()) {
ColumnReference indexColumn = coveredColumnsMap.get(ref);
// If table delete was single version, then index delete should
be as well
if (deleteType == DeleteType.SINGLE_VERSION) {
delete.deleteFamilyVersion(indexColumn.getFamily(), ts);
} else {
delete.deleteFamily(indexColumn.getFamily(), ts);
}
}
if (deleteType == DeleteType.SINGLE_VERSION) {
delete.deleteFamilyVersion(emptyCF, ts);
} else {
delete.deleteFamily(emptyCF, ts);
}
delete.setDurability(!indexWALDisabled ? Durability.USE_DEFAULT :
Durability.SKIP_WAL);
return delete;
}
........
{code}
> Extra DeleteFamily marker in non tx index table when setting covered column
> to null
> -----------------------------------------------------------------------------------
>
> Key: PHOENIX-3685
> URL: https://issues.apache.org/jira/browse/PHOENIX-3685
> Project: Phoenix
> Issue Type: Bug
> Reporter: James Taylor
> Assignee: Thomas D'Silva
> Attachments: PHOENIX-3685-test.patch
>
>
> Based on some testing (see patch), I noticed a mysterious DeleteFamily marker
> when a covered column is set to null. This could potentially delete an actual
> row with that row key, so it's bad.
> Here's a raw scan dump taken after the MutableIndexIT.testCoveredColumns()
> test:
> {code}
> ************ dumping IDX_T000002;hconnection-0x211e75ea **************
> \x00a/0:/1487356752097/DeleteFamily/vlen=0/seqid=0 value =
> x\x00a/0:0:V2/1487356752231/Put/vlen=1/seqid=0 value = 4
> x\x00a/0:0:V2/1487356752225/Put/vlen=1/seqid=0 value = 4
> x\x00a/0:0:V2/1487356752202/Put/vlen=1/seqid=0 value = 3
> x\x00a/0:0:V2/1487356752149/DeleteColumn/vlen=0/seqid=0 value =
> x\x00a/0:0:V2/1487356752097/Put/vlen=1/seqid=0 value = 1
> x\x00a/0:_0/1487356752231/Put/vlen=2/seqid=0 value = _0
> x\x00a/0:_0/1487356752225/Put/vlen=2/seqid=0 value = _0
> x\x00a/0:_0/1487356752202/Put/vlen=2/seqid=0 value = _0
> x\x00a/0:_0/1487356752149/Put/vlen=2/seqid=0 value = _0
> x\x00a/0:_0/1487356752097/Put/vlen=2/seqid=0 value = _0
> -----------------------------------------------
> {code}
> That first DeleteFamily marker shouldn't be there. This occurs for both
> global and local indexes, but not for transactional tables. A further
> optimization would be not to issue the first Put since the value behind it is
> the same.
> On the plus side, we're not issuing DeleteFamily markers when only the
> covered column is being set which is good.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
