jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Mueller" <thomas.tom.muel...@gmail.com>
Subject Re: Query performance for large query results
Date Tue, 28 Nov 2006 09:08:33 GMT
Hi,

I didn't know that checking access rights is so expensive... For me,
checking access rights doesn't 'sound' like it should be a performance
problem. But I think I understand why it is at the moment. I hope that
at some point we can find a solution to speed this up or delegate it
to the search index (currently Lucene).

Anyway, from an API / user perspective, setLimit and setOffset are
often used together, for paging. And in many cases the underlying
engine can be implemented more efficiently when it knows the offset
and the actual number of elements the client will read - before the
query is executed. This are the main reasons why I suggested
setOffset.

Thomas




On 11/28/06, Marcel Reutegger <marcel.reutegger@gmx.net> wrote:
> Thomas Mueller wrote:
> > My reason to ask for setOffset was, I was hoping the performance can
> > optimized more easily. Skip needs to be called after getNodes. If
> > getNodes already 'knows' before how many nodes will be skipped, then
> > it may be easier to optimize getNodes (in the future). Of course this
> > is my assumption, and may not be true at all, and for me optimizing it
> > is not a high priority. getNodes could just fetch the whole result in
> > one step if the limit is smaller than some number. This may save you
> > one network call. But as far as I know there is no setOffset in Lucene
> > currently. I'm OK even without setOffset.
>
> The expensive part is checking access rights on a potential node to return. The
> current implementation using lucene requires getting the document from the index
> to find out the uuid of the node and then check access using this uuid. Skipping
> results in lucene alone wouldn't be a big deal, but we need to find out how many
> documents to skip the user has actually access too :-/
>
> regards
>   marcel
>
>

Mime
View raw message