[
https://issues.apache.org/jira/browse/HBASE-5980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14515056#comment-14515056
]
Jonathan Lawlor commented on HBASE-5980:
----------------------------------------
bq. you need to add this option to the Scan help in the shell else no one will
find it.
Good point. Added explanation and examples to the scan help in next patch.
bq. I'd say drop the 'GET_'... because redundant
I like this proposal. Changed to ALL_METRICS and METRICS in latest patch
bq. Purge the abstract class? Only used once?
Makes sense to me. Purged the abstract class in latest patch and moved all of
its functionality into ServerSideMetrics in latest patch.
bq. Should we have ClientScanMetrics and ServerScanMetrics?
Hmm, interesting idea. So something like: add new class "ClientScanMetrics" and
have instances of both "ClientScanMetrics" and "ServerScanMetrics" as members
of a ScanMetrics instance? Since ScanMetrics is a public-evolving API, I think
this change would be okay. The change would be beneficial in a clean-code
sense. As a user, I don't think the distinction between client-side vs.
server-side would be too important when looking at the metrics (a user probably
just cares that a metric exists, not whether it is classified as server-side or
client-side). How does that sound, worth doing?
Note: In the latest patch I have also changed the interface audience of
ServerSideScanMetrics to public-evolving to match the existing interface
annotation of ScanMetrics. I did this because it seemed wrong that a
public-evolving class inherited from a private class.
> Scanner responses from RS should include metrics on rows/KVs filtered
> ---------------------------------------------------------------------
>
> Key: HBASE-5980
> URL: https://issues.apache.org/jira/browse/HBASE-5980
> Project: HBase
> Issue Type: Improvement
> Components: Client, metrics, regionserver
> Affects Versions: 0.95.2
> Reporter: Todd Lipcon
> Assignee: Jonathan Lawlor
> Priority: Minor
> Attachments: HBASE-5980-v1.patch
>
>
> Currently it's difficult to know, when issuing a filter, what percentage of
> rows were skipped by that filter. We should expose some basic counters back
> to the client scanner object. For example:
> - number of rows filtered by row key alone (filterRowKey())
> - number of times each filter response was returned by filterKeyValue() -
> corresponding to Filter.ReturnCode
> What would be slickest is if this could actually return a tree of counters
> for cases where FilterList or other combining filters are used. But a
> top-level is a good start.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
