Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (herse.apache.org: domain of marcel.reutegger@gmx.net
 designates 213.165.64.20 as permitted sender)
Message-ID: <45F7E2F2.4050303@gmx.net>
Date: Wed, 14 Mar 2007 12:56:34 +0100
From: Marcel Reutegger <marcel.reutegger@gmx.net>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: dev@jackrabbit.apache.org
Subject: Re: Query Performance and Optimization
References: <4f95e0110702272149l3b409fd4h936a381868f5fbc9@mail.gmail.com>
	 <4f95e0110703021130p47c7353am5722aba05970498@mail.gmail.com>
	 <45ED33B9.5070707@gmx.net>
	 <4f95e0110703070603r7992fa7fg3af716264e3698df@mail.gmail.com>
	 <45F16E5C.6000703@gmx.net>
	 <4f95e0110703091130l73ee6d5mdb7d3a112f520b01@mail.gmail.com>
	 <45F57249.1050901@gmx.net>
	 <4f95e0110703121553q2e15b3dem2b99f195c0f4816e@mail.gmail.com>
	 <96ab3ced0703121727m5cf8d9cdvacf76f5da4c52fbd@mail.gmail.com>
	 <45F668E0.8010008@gmx.net>
 <4f95e0110703131251v6fe7c017rc5e6daf954fdeb1f@mail.gmail.com>
In-Reply-To: <4f95e0110703131251v6fe7c017rc5e6daf954fdeb1f@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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.

regards
  marcel