[
https://issues.apache.org/jira/browse/JCR-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561686#action_12561686
]
Ard Schrijvers commented on JCR-1337:
-------------------------------------
"Reading the parent information is independent of how the ids are distributed.
The read is fast because there is no random access involved. The lucene
documents can be read sequentially from disk. "
But if the number of foreignParents becomes larger (through many node updates
for example) then looking up parent information and thus pre-warming becomes
slower, or am i missing something? If
else if (info.parent != null) {
foreignParents++;
parents[info.docId] = DocId.create(info.parent);
}
needs to be executed more often I suppose the initializeParents becomes slower.
Either I am missing something or my previous comment was unclear.
"On my machine indexes are merged at about 10k nodes per second. Though merging
is completely done in the background, while initializing the cache (using the
current patch) is done by the first thread that accesses the new index segment
after the merge."
Might background pre-warming be an option?
> Optimize first execution queries for DescendantSelfAxisWeight/ChildAxisQuery
> ----------------------------------------------------------------------------
>
> Key: JCR-1337
> URL: https://issues.apache.org/jira/browse/JCR-1337
> Project: Jackrabbit
> Issue Type: Improvement
> Components: query
> Affects Versions: 1.4
> Reporter: Ard Schrijvers
> Fix For: 2.0
>
> Attachments: JCR-1337.patch, JCR-1337.patch
>
>
> The first execution of a query involving
> DescendantSelfAxisWeight/ChildAxisQuery is slow. Consecutive queries are
> faster because the hierarchy is cached
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
