jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christoph Kiehl <christ...@sulu3000.de>
Subject Re: Search performance : MultiIndex
Date Wed, 31 Oct 2007 07:54:55 GMT
Marcel Reutegger wrote:

> I'd like to keep a move operation cheap but I also agree that 
> hierarchical query operations need to be improved.

Same here. Making move operations expensive is a very high price for getting 
fast queries. Although I'm not sure how common the usecase of moving big 
subtrees is?

> we should definitively try to execute such queries in a reasonable time. 
> I think this is a very common use case. can you please create a jira 
> issue? I'm not sure if the hierarchy is the issue here or just the fact 
> that lots of nodes need to be ordered. do you have more insight on this?

Ordering should be ok since we resolved JCR-974. Although it would still be nice 
to have a less memory intensive solution (all FieldCaches are hold in memory).

>> Obviously, this only works when I index a node's path in some lucene
>> field. So a node with path /documents/en/news/2007/10/14/item.xml
>> would have lucene Field that contains the terms
>> '/documents/en/news/2007/10/14/item.xml'
>> '/documents/en/news/2007/10/14'
>> '/documents/en/news/2007/10'
>> '/documents/en/news/2007'
>> '/documents/en/news'
>> '/documents/en'
>> '/documents'
> maybe this approach can be turned into a clever hierarchical cache? 
> without the need to index the whole path with a node.

My hope is that we find exactly that kind of clever cache ;) I even think we 
should make this one persistent because you have to read every node to build it 
and I think it might consume to much memory for big repositories (at least if we 
keep the paths human readable like above).

Maybe I have some time on Friday to think about it. But maybe Ard is faster to 
come up with a solution ;))


View raw message