[jira] [Commented] (PHOENIX-5558) Eliminate the second single data row scan during read repairs

["Hadoop QA (Jira)" <ji...@apache.org>]

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

Hadoop QA commented on PHOENIX-5558:
------------------------------------

{color:red}-1 overall{color}.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12984874/PHOENIX-5558.master.001.patch
  against master branch at commit 0aa7d5722d92126d2e50fd2b1346c57305c4d745.
  ATTACHMENT ID: 12984874

    {color:green}+1 @author{color}.  The patch does not contain any @author tags.

    {color:red}-1 tests included{color}.  The patch doesn't appear to include any new or modified tests.
                        Please justify why no new tests are needed for this patch.
                        Also please list what manual steps were performed to verify this patch.

    {color:green}+1 javac{color}.  The applied patch does not increase the total number of javac compiler warnings.

    {color:green}+1 release audit{color}.  The applied patch does not increase the total number of release audit warnings.

    {color:red}-1 lineLengths{color}.  The patch introduces the following lines longer than 100:
    +                public ImmutableBytesWritable getLatestValue(ColumnReference ref, long ts) throws IOException {
+                    valuePtr.set(cell.getValueArray(), cell.getValueOffset(), cell.getValueLength());
+            byte[] builtIndexRowKey = indexMaintainer.buildRowKey(getter, new ImmutableBytesWritable(put.getRow()),
+                                // GlobalIndexChecker passed the index row key. This is to build a single index row.
+                                // Check if the data table row we have just scanned matches with the index row key.
+                                // If not, there is no need to build the index row from this data table row,
+                buildIndexScan.addColumn(indexMaintainer.getDataEmptyKeyValueCF(), indexMaintainer.getEmptyKeyValueQualifier());
+            // Pass the index row key to the partial index builder which will build the index row only when the data
+            long rowCount = PLong.INSTANCE.getCodec().decodeLong(new ImmutableBytesWritable(value), SortOrder.getDefault());

     {color:red}-1 core tests{color}.  The patch failed these unit tests:
     ./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.MutableIndexIT

Test results: https://builds.apache.org/job/PreCommit-PHOENIX-Build/3092//testReport/
Console output: https://builds.apache.org/job/PreCommit-PHOENIX-Build/3092//console

This message is automatically generated.

> Eliminate the second single data row scan during read repairs
> -------------------------------------------------------------
>
>                 Key: PHOENIX-5558
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-5558
>             Project: Phoenix
>          Issue Type: Improvement
>    Affects Versions: 5.1.0
>            Reporter: Kadir OZDEMIR
>            Assignee: Kadir OZDEMIR
>            Priority: Major
>         Attachments: PHOENIX-5558.master.001.patch
>
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> Initially GlobalIndexChecker used a raw scan to rebuild an index row in order to replay delete markers while rebuilding the row. Although a single index row was rebuilt, the number of mutations that are replayed could be one or more. Because of this, GlobalIndexChecker could not determine if the data table row corresponding to the unverified index row exists or not by just looking at the mutation count returned by UngroupedAggregateRegionObserver. Thus, GlobalIndexChecker had to do another single row scan on the data table to find out if the data table row exist. After PHOENIX-5535, GlobalIndexChecker does not use raw scans anymore. This means that the second single data table row scan during the read repair can be eliminated.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)