Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <23565778.1202479276434.JavaMail.jira@brutus>
Date: Fri, 8 Feb 2008 06:01:16 -0800 (PST)
From: "Alex Lukin (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Issue Comment Edited: (JCR-1365) Query path constraints like
 foo//*/bar do not scale
In-Reply-To: <29127819.1202476147562.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/JCR-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567042#action_12567042 ] 

alukin edited comment on JCR-1365 at 2/8/08 6:00 AM:
---------------------------------------------------------

Most users do not bother with complicated XPath query to find nodes. Usually content modeled such way that node contains subnodes of one type. So query //foo/*/bar is quite common. Speed of this query is simply depressive. 200 nodes in 3 levels makes debugger "think" on query.execute() for minutes and then minutes on getting trough iterator. 

IMHO, it is high priority task.I've herad a lot of bad words from colleagues about Lucene in general and about Lucene in Jackrabbit and I think that the cause of all it is bad speed on such simple queries.

May be It would be nice to be abble start guery not for entire workplace but for some node?
Could it speedup search? 

      was (Author: alukin):
    Most users do not bother with complicated XPath query to find nodes. Usually content modeled such way that node contains subnodes of one type. So query //foo/*/bar is quite common. Speed of this query is simply depressive. 200 nodes in 3 levels makes debugger "think" on query.execute() for minutes and then minutes on getting trough iterator. 

IMHO, it is high priority task.I've herad a lot of bad words from colleagues about Lucene in general and about Lucene in Jackrabbit and I think that the cause of all it is bad speed on such simple queries.
  
> Query path constraints like foo//*/bar do not scale
> ---------------------------------------------------
>
>                 Key: JCR-1365
>                 URL: https://issues.apache.org/jira/browse/JCR-1365
>             Project: Jackrabbit
>          Issue Type: Improvement
>          Components: jackrabbit-core
>            Reporter: Marcel Reutegger
>            Priority: Minor
>
> To resolve the * step the LuceneQueryBuilder currently creates a MatchAllQuery and checks every node for a foo ancestor. Instead, it should search for bar nodes and check for foo ancestors with at least one arbitrary hierarchy level in between.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.