On Thu, Feb 13, 2014 at 11:49 AM, Mikhail Khludnev <[email protected]> wrote: > Mike, > Thanks for the clue. It raises a lot of questions: > - Is this cost caused by random access nature of the seekCeil() /** The > target term may be before or after the current term. */? Is there any chance > to make it more efficient by requesting "forward only" TermEnum?
Maybe we could get some gains with a "forward only" mode ... not sure. The enum already shares state, i.e. it checks for the common prefix b/w the term it's on now and the term you're seeking to. But also traversing the FST is not cheap. > - will it be faster with 'entirely memory residend term dictionary'? Likely ... > - or the overall idea of using TermEnum just complies with the sub, and > it's worth to experiment with writing the previous parent docnum (or current > block size) in payload and reading it when we need to jump back on > advance()? Maybe? But I think using FBS is an OK solution too... that's a very fast way to find prev/next parent. > - once again, would you mind to remind why making DocEnum capable to jump > back is so hard? Can you recommend any starting point for hacking? Well, all the impls are heavily "forward only", e.g. we store the doc deltas in an int[128] and sum as we go. But anything we can do to improve block join, or query time join, would be great. E.g. for query time join I think this issue would be a big win: https://issues.apache.org/jira/browse/LUCENE-4771 Mike McCandless http://blog.mikemccandless.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
