[
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
(v6.3.4#6332)
