Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Wed, 18 Oct 2017 05:41:03 +0000 (UTC)
From: "Lars Hofhansl (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.13066610.1493108885000.23633.1508305263363@Atlassian.JIRA>
In-Reply-To: <JIRA.13066610.1493108885000@Atlassian.JIRA>
References: <JIRA.13066610.1493108885000@Atlassian.JIRA> <JIRA.13066610.1493108885882@jira-lw-us.apache.org>
Subject: [jira] [Comment Edited] (HBASE-17958) Avoid passing unexpected cell
 to ScanQueryMatcher when optimize SEEK to SKIP
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Wed, 18 Oct 2017 05:41:12 -0000


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

Lars Hofhansl edited comment on HBASE-17958 at 10/18/17 5:40 AM:
-----------------------------------------------------------------

I can fairly easily eliminate the repeated compare to the next indexed key - that does shave off only about 5% of the overall scan time, so not a lot, but measurable. I don't think there's any point to check again inside the loop.

The duplicate compares in trySkipToNextRow and trySkipToNextCol are still there and the column trackers are still there, though. Those could only be avoided by sending the fake cells all the up to the columnTracker, I agree that wasn't nice, maybe we can come with other way to eliminate this cost.
HBase is slow in scanning. Perhaps these micro-optimizations aren't worth it.

[~stack]


was (Author: lhofhansl):
I can fairly easily eliminate the repeated compare to the next indexed key - that does shave off only about 5% of the overall scan time, so not a lot, but measurable. I don't think there's any point to check again inside the loop.

The duplicate compares in trySkipToNextRow and trySkipToNextCol are still there and the column trackers are still there, though. Those could only be avoided by sending the fake cells all the up to the columnTracker, I agree that wasn't nice, maybe we can come with other way to eliminate this cost.
HBase is slow in scanning. Perhaps these micro-optimizations aren't worth it.

> Avoid passing unexpected cell to ScanQueryMatcher when optimize SEEK to SKIP
> ----------------------------------------------------------------------------
>
>                 Key: HBASE-17958
>                 URL: https://issues.apache.org/jira/browse/HBASE-17958
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Guanghao Zhang
>            Assignee: Guanghao Zhang
>             Fix For: 2.0.0, 1.4.0
>
>         Attachments: 0001-add-one-ut-testWithColumnCountGetFilter.patch, HBASE-17958-branch-1.patch, HBASE-17958-branch-1.patch, HBASE-17958-branch-1.patch, HBASE-17958-branch-1.patch, HBASE-17958-v1.patch, HBASE-17958-v2.patch, HBASE-17958-v3.patch, HBASE-17958-v4.patch, HBASE-17958-v5.patch, HBASE-17958-v6.patch, HBASE-17958-v7.patch, HBASE-17958-v7.patch
>
>
> {code}
> ScanQueryMatcher.MatchCode qcode = matcher.match(cell);
> qcode = optimize(qcode, cell);
> {code}
> The optimize method may change the MatchCode from SEEK_NEXT_COL/SEEK_NEXT_ROW to SKIP. But it still pass the next cell to ScanQueryMatcher. It will get wrong result when use some filter, etc. ColumnCountGetFilter. It just count the  columns's number. If pass a same column to this filter, the count result will be wrong. So we should avoid passing cell to ScanQueryMatcher when optimize SEEK to SKIP.


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)