lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Stoppelman" <stop...@gmail.com>
Subject Re: QueryWrapperFilter question...
Date Thu, 17 Apr 2008 04:37:18 GMT
Actually, I screwed up the timing info. I wasn't including the time for the
QueryWrapperFilter#bits(IndexReader) call. Sadly,
it actually takes longer than the original query that had both terms
included. Bummer. I had really convinced myself till the
thought came to me at lunch :).

-M


On Wed, Apr 16, 2008 at 6:43 PM, Karl Wettin <karl.wettin@gmail.com> wrote:

> Michael Stoppelman skrev:
>
>  Hi all,
> > I've been doing some performance testing and found that using
> > QueryWrapperFilter for a location field
> > restriction I have to do allows my search results to approach 5-10ms.
> > This
> > was surprising.
> > Before the performance was between 50ms-100ms.
> >
> > The queries from before the optimization look like the following:
> > +(+(text:cats) +(loc:1 loc:2 loc:3 ...))
> >
> > The QueryWrapperFilter does do a search itself. Why would performance be
> > so
> > drastically different when the
> > QueryWrapperFilter needs to do a search? Does lucene just not have the
> > statistics to optimize this query so it
> > can decide which terms to filter by first?
> >
>
> Do you wonder why a QueryWrapperFilter is faster than a Query? Then the
> answer is that the filter uses a bitset to know if a document matches a
> document or not. For each document that match text:cats it checks the flag
> in the bitset for that document number instead of seeking in the index to
> find out if also match loc:1, loc:2 or loc:3.
>
>
>     karl
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message