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


Mime
View raw message