After some more research, it seems that one of the bottlenecks is Spans.next(), can I drop anything out in order to improve performance? Most of the queries are SpanNearQuery with SpanOrQuery as its clauses.
Any help would be much appreciated. Regards, Michael On 5/25/06, Michael Chan <[EMAIL PROTECTED]> wrote:
I see. Also, as I'm only interested in the number of results returned and not in the ranking of documents returned, is there any component I can simplify in order to improve search performance? Perhaps, Scorer or Similarity? Thanks. Michael On 5/24/06, Chris Hostetter <[EMAIL PROTECTED]> wrote: > > : Unfortunately, I want to have subqueries inside my query (e.g. (t1 AND > : t2) NEAR (t3 OR t4)), and PhraseQuery seems to allow only Terms inside > : it. > > In that case, you aren't just using SpanQuery for the use of slop -- you > are using the Span information, you just don't realize it (that's how all > of the SpanQueries work -- the get the Slop information from the sub > queries and propogate them up. (which is also why you can't use just any > only Query as a clause in a SpanNearQuery) > > : > > As I use SpanQuery purely for the use of slop, I was wondering how to > : > > make SpanQuery more efficient,. Since I don't need any span > : > > information, is there a way to disable the computation for span and > : > > other unneeded overhead? > > > > -Hoss > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
