hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dave Latham (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-13442) Rename scanner caching to a more semantically correct term such as row limit
Date Tue, 21 Apr 2015 21:11:59 GMT

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

Dave Latham commented on HBASE-13442:

It may be good to understand how people actually want to use this thing  In my mind the client
API and the protocol to the server are two separate things.  I can see applications that want
to scan N rows from a given start point.  To support them we could put a rowLimit in the client
API or require row filters.  The protocol itself could still allow the client to ask the server
for N rows or M bytes, whichever comes first.  If the app is not actually limiting its results,
I don't see why an app should care specifically about how many rows the client transfers from
the server in each RPC - bytes seem the more relevant currency to tune for performance. 

> Rename scanner caching to a more semantically correct term such as row limit
> ----------------------------------------------------------------------------
>                 Key: HBASE-13442
>                 URL: https://issues.apache.org/jira/browse/HBASE-13442
>             Project: HBase
>          Issue Type: Sub-task
>            Reporter: Jonathan Lawlor
>         Attachments: HBASE-13442-proposal.diff
> Caching acts more as a row limit now. By default in branch-1+, a Scan is configured with
(caching=Integer.MAX_VALUE, maxResultSize=2MB) so that we service scans on the basis of buffer
size rather than number of rows. As a result, caching should now only be configured in instances
where the user knows that they will only need X rows. Thus, caching should be renamed to something
that is more semantically correct such as rowLimit.

This message was sent by Atlassian JIRA

View raw message