jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ard Schrijvers" <a.schrijv...@hippo.nl>
Subject RE: Search performance : MultiIndex
Date Tue, 30 Oct 2007 11:29:27 GMT

> Ard Schrijvers wrote:
> I think these problems can only be solved by having all 
> criteria present in the index. I do not directly see how a 
> hierarchical cache could solve the issue. Using this cache to 
> filter afterwards will inherently again result in slow 
> results, beside the fact that the cache might become pretty 
> big to be effective. 
> Anyway, I'll try to get back on the issue with some findings 
> of the current impl next week

Thinking some more about it, perhaps we can get away without changing
the index, but merely the order in which the current search is done
(though i am not sure because not yet investigated so from top of my
head). I think the current search checks for all hits via recursive
filters wether they have the correct parents. I think though that it
shouldn't be to hard to first create a filter of the initial path, for
example a BitSet for something like

/documents/en/news or
/documents/en[1]/news or 
/documents/*/news or
/documents/en[@country='england']/news etc

When having this filter, the rest lucene should do it trivial. Creating
this filter might involve some filtering of filtering of filtered
BitSet's, but I think this shouldn't be to slow, and it might be easily
cached for some time. 

Anyway, I'll look into it

Regards Ard

View raw message