jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Serge Huber (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-2835) Poor performance of ISDESCENDANTNODE on SQL 2 queries
Date Mon, 13 Dec 2010 07:02:02 GMT

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

Serge Huber commented on JCR-2835:
----------------------------------

Sorry about that Jukka, my bad. Didn't know this could cause Hudson to fail.

Btw unfortunately I didn't have the time to test your proposal. I was working on comparing
the Lucene queries between the XPath and SQL-2 tests, and saw that the DescendantChildNodeQuery
is being used in the case of XPath but not in the case of SQL-2. I'm not (yet) an expert at
Lucene, but maybe that's a place to start ? 

I also notice that the SimpleQueryResult does not support result fetch size as the other SingleColumnQueryResult
and MultipleColumnQueryResult do. I realize this is because of the join merging, but maybe
we should look at being able to do "progressive" merging alongside with merges in order to
reduce the number of results being loaded systematically. Again I haven't thought this through
completely and maybe there is some limitation on doing so.

These query problems are difficult because we are basically rewriting a full-fledged SQL optimizer,
and maybe we should look at how databases perform these ?

Regards,
  Serge Huber.

> Poor performance of ISDESCENDANTNODE on SQL 2 queries
> -----------------------------------------------------
>
>                 Key: JCR-2835
>                 URL: https://issues.apache.org/jira/browse/JCR-2835
>             Project: Jackrabbit Content Repository
>          Issue Type: Improvement
>          Components: jackrabbit-core, query
>    Affects Versions: 2.2.0, 2.2.1, 2.3.0
>            Reporter: Serge Huber
>             Fix For: 2.3.0
>
>         Attachments: JCR-2835_PerformanceTests.patch, JCR-2835_Poor_performance_on_ISDESCENDANTNODE_constraint_v1.patch
>
>
> Using the latest source code, I have noticed very bad performance on SQL-2 queries that
use the ISDESCENDANTNODE constraint on a large sub-tree. For example, the query : 
> select * from [jnt:news] as news where ISDESCENDANTNODE(news,'/root/site') order by news.[date]
desc 
> executes in 600ms 
> select * from [jnt:news] as news order by news.[date] desc
> executes in 4ms
> From looking at the problem in the Yourkit profiler, it seems that the culprit is the
constraint building, that uses recursive Lucene searches to build the list of descendant node
IDs : 
>     private Query getDescendantNodeQuery(
>             DescendantNode dn, JackrabbitIndexSearcher searcher)
>             throws RepositoryException, IOException {
>         BooleanQuery query = new BooleanQuery();
>         try {
>             LinkedList<NodeId> ids = new LinkedList<NodeId>();
>             NodeImpl ancestor = (NodeImpl) session.getNode(dn.getAncestorPath());
>             ids.add(ancestor.getNodeId());
>             while (!ids.isEmpty()) {
>                 String id = ids.removeFirst().toString();
>                 Query q = new JackrabbitTermQuery(new Term(FieldNames.PARENT, id));
>                 QueryHits hits = searcher.evaluate(q);
>                 ScoreNode sn = hits.nextScoreNode();
>                 if (sn != null) {
>                     query.add(q, SHOULD);
>                     do {
>                         ids.add(sn.getNodeId());
>                         sn = hits.nextScoreNode();
>                     } while (sn != null);
>                 }
>             }
>         } catch (PathNotFoundException e) {
>             query.add(new JackrabbitTermQuery(new Term(
>                     FieldNames.UUID, "invalid-node-id")), // never matches
>                     SHOULD);
>         }
>         return query;
>     }
> In the above example this generates over 2800 Lucene queries, which is the culprit. I
wonder if it wouldn't be faster to retrieve the IDs by using the JCR to retrieve the list
of child IDs ?
> This was probably also missed because I didn't seem to find any performance tests on
this constraint.

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