[
https://issues.apache.org/jira/browse/JCR-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567042#action_12567042
]
Alex Lukin commented on JCR-1365:
---------------------------------
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.
