jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Lukin (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-1365) Query path constraints like foo//*/bar do not scale
Date Fri, 08 Feb 2008 13:59:08 GMT

    [ 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.


Mime
View raw message