jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <marcel.reuteg...@gmx.net>
Subject Re: Query Performance and Optimization
Date Wed, 14 Mar 2007 11:56:34 GMT
David Johnson wrote:
> While I can see how my suggested optimization could severely impact some 
> use
> cases.  Nevertheless, "our use case" :-) is mostly querying a stable
> hierarchy structure - i.e., we rarely, if ever, would move a tree with even
> 1000s of sub-nodes (famous last words).  And we use the node hierarchy in
> our queries --- well, always!
> The balance between use cases is suggesting to me the need for
> administratively defined indexes that could be used by the query processing
> engine if they existed.  So that users (repository administrators) could
> define the indexes - like this one - with the knowledge that certain
> operations (a move) would require a fairly expensive rebuild of the 
> indexing
> structures.
> Could you give some more detail on how ChildAxisQuery and
> DescendantSelfAxisQuery work.  On first read, the comment at the beginning
> were not completely clear to me - more than likely related to me.  I 
> think I
> get what they are doing, I just would like a little more overview, to help
> me before jumping in and attempting to understand the code.  It seems that
> the query parser breaks down a path into its pieces, and this is then fed
> into the LuceneQueryParser as location steps - and these get changed into
> ChildAxisQuery or DescendantSelfAxisQuery as appropriate?

that's correct. both queries have a context query. the matches of the context 
query is then used as a starting point to 'calculate' the child nodes or 
descendant-or-self nodes.


View raw message