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.

View raw message