Return-Path: X-Original-To: apmail-hbase-issues-archive@www.apache.org Delivered-To: apmail-hbase-issues-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 77D7610DCB for ; Wed, 16 Oct 2013 18:01:54 +0000 (UTC) Received: (qmail 41681 invoked by uid 500); 16 Oct 2013 18:01:53 -0000 Delivered-To: apmail-hbase-issues-archive@hbase.apache.org Received: (qmail 41398 invoked by uid 500); 16 Oct 2013 18:01:53 -0000 Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list issues@hbase.apache.org Received: (qmail 40971 invoked by uid 99); 16 Oct 2013 18:01:49 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 Oct 2013 18:01:49 +0000 Date: Wed, 16 Oct 2013 18:01:49 +0000 (UTC) From: "Jesse Yates (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HBASE-9778) Avoid seeking to next column in ExplicitColumnTracker when possible MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HBASE-9778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13797064#comment-13797064 ] Jesse Yates commented on HBASE-9778: ------------------------------------ Feels like we should be smarter here: {quote} + // is interested in, so skip or seek to that column of interest. + return storeMaxVersions == 1 ? ScanQueryMatcher.MatchCode.SKIP + : ScanQueryMatcher.MatchCode.SEEK_NEXT_COL; {quote} Why not keep a count of the versions seen and only skip past if approaching (at?) the number of max versions? Shouldn't need any synchronization on that member variable, so access should be fast > Avoid seeking to next column in ExplicitColumnTracker when possible > ------------------------------------------------------------------- > > Key: HBASE-9778 > URL: https://issues.apache.org/jira/browse/HBASE-9778 > Project: HBase > Issue Type: Bug > Reporter: Lars Hofhansl > Assignee: Lars Hofhansl > Fix For: 0.98.0, 0.94.13, 0.96.1 > > Attachments: 9778-0.94.txt, 9778-0.94-v2.txt, 9778-trunk.txt, 9778-trunk-v2.txt > > > The issue of slow seeking in ExplicitColumnTracker was brought up by [~vrodionov] on the dev list. > My idea here is to avoid the seeking if we know that there aren't many versions to skip. > How do we know? We'll use the column family's VERSIONS setting as a hint. If VERSIONS is set to 1 (or maybe some value < 10) we'll avoid the seek and call SKIP repeatedly. > HBASE-9769 has some initial number for this approach: > Interestingly it depends on which column(s) is (are) selected. > Some numbers: 4m rows, 5 cols each, 1 cf, 10 bytes values, VERSIONS=1, everything filtered at the server with a ValueFilter. Everything measured in seconds. > Without patch: > ||Wildcard||Col 1||Col 2||Col 4||Col 5||Col 2+4|| > |6.4|8.5|14.3|14.6|11.1|20.3| > With patch: > ||Wildcard||Col 1||Col 2||Col 4||Col 5||Col 2+4|| > |6.4|8.4|8.9|9.9|6.4|10.0| > Variation here was +- 0.2s. > So with this patch scanning is 2x faster than without in some cases, and never slower. No special hint needed, beyond declaring VERSIONS correctly. -- This message was sent by Atlassian JIRA (v6.1#6144)