[
https://issues.apache.org/jira/browse/HBASE-5980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Lawlor updated HBASE-5980:
-----------------------------------
Attachment: HBASE-5980-v3.patch
Here's an updated patch with some new tests. The tests now stress more filter
scenarios as well as different scan configurations (varying values of caching
and max result size).
Moved around the increment to the number of rows scanned to put it in a better
spot (I agree with [~anoop.hbase] that it doesn't belong in nextRow). Now it is
incremented within populateResult once we have recognized that there are no
more cells in the row.
Let's see what QA has to say about this one, looks like the patch causing
issues with test failures has been reverted so should be a cleaner run.
> 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-branch-1.patch, HBASE-5980-v1.patch,
> HBASE-5980-v2.patch, HBASE-5980-v2.patch, HBASE-5980-v3.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)
