[jira] [Comment Edited] (OAK-2730) Faster result count estimation for QueryResult on lines of resultFetchSize support in JR2

["angela (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/OAK-2730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14486850#comment-14486850 ] 

angela edited comment on OAK-2730 at 4/9/15 6:52 AM:
-----------------------------------------------------

[~mmarth], see OAK-2423 for paths-based read-access evaluation. i already provided an initial patch for [~teofili] in the light of the faceted search. however, it is important to note, that with additional restrictions that require to know about the type of the item (such as e.g. OAK-2437) the evaluation might not be a 100% equivalent and denying access where it might actually be granted... i guess for search results we might be willing to live with this potential limitation. in any case i would strongly recommend to not introduce such an optimization without adding dedicated benchmarks.


was (Author: anchela):
[~mmarth], see OAK-2423 for paths-based permission evaluation. i already provided an initial patch for [~teofili] in the light of the faceted search. however, it is important to note, that with additional restrictions that require to know about the type of the item (such as e.g. OAK-2437) the evaluation might not be a 100% equivalent and denying access where it might actually be granted... i guess for search results we might be willing to live with this potential limitation. in any case i would strongly recommend to not introduce such an optimization without adding dedicated benchmarks.

> Faster result count estimation for QueryResult on lines of resultFetchSize support in JR2
> -----------------------------------------------------------------------------------------
>
>                 Key: OAK-2730
>                 URL: https://issues.apache.org/jira/browse/OAK-2730
>             Project: Jackrabbit Oak
>          Issue Type: New Feature
>          Components: query
>            Reporter: Chetan Mehrotra
>             Fix For: 1.3.0
>
>
> Currently in Oak while fetching the result size for a query the time taken is proportional to the result size. This would not perform well when result size is big. The complete traversal is required to perform ACL check to ensure that result count is *accurate*
> JR2 used to support {{resultFetchSize}} (default to integer max).  This was used to get an estimate of possible result count whereby the count might not be accurate.
> Per [~mreutegg] this feature worked like below
> {quote}
> If resultFetchSize is set to 50 then QueryEngine will initially collect up to 50 nodes the current session is allowed to read from the raw lucene result set. While doing that, it counts the number of nodes denied by access control checks. The result size reported is then calculated as: raw-lucene-result-size - number-of-nodes-denied. The resultFetchSize is double and the query executed again if a client iterates passed the currently available nodes. If it is required to have an exact result size, then the configuration for 'resultFetchSize' can be increased to a much higher value. However, this has a severe performance impact for large result sets, because the query will now have to apply access control checks for the complete result set
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)