You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Peter Wolanin <pe...@acquia.com> on 2009/02/21 03:21:53 UTC

What is the performance impact of a fq that matches all docs?

We are working on integration with the Drupal CMS, and so are writing
code that carries out operations that might only be relevant for only
a small subset of the sites/indexes that might use the integration
module.  In this regard, I'm wondering if adding to the query (using
the dismax or mlt handlers) a fq that matches all documents would have
any impact on performance?  I gatehr that there is caching for the fq
matches, but it seems liek that would still incur some overhead,
especially for a large index?

As a more concrete example, suppose each document has a string field
that names the role of user that is allowed to see the content.  e.g.
'public', 'registered', 'admin'.  Most sites have only public content,
but because our code is generic, we might add  &fq=role:public to
every query.  What would the expected performance effect be compared
to omitting that fq if, for example, we had a way to determine in
advance that all site content matches 'public'.

Thanks,

Peter

-- 
Peter M. Wolanin, Ph.D.
Momentum Specialist,  Acquia. Inc.
peter.wolanin@acquia.com

Re: What is the performance impact of a fq that matches all docs?

Posted by Yonik Seeley <yo...@lucidimagination.com>.
Since fq=role:public will be cached and reused for all the queries
that use it, the performance impact will be very small.  Once it's
cached, there currently won't be a difference between a filter
matching 10% of the index vs the whole index since the filtering code
is doing a check of a bit in a bitset.


-Yonik
Lucene/Solr? http://www.lucidimagination.com

On Fri, Feb 20, 2009 at 9:21 PM, Peter Wolanin <pe...@acquia.com> wrote:
> We are working on integration with the Drupal CMS, and so are writing
> code that carries out operations that might only be relevant for only
> a small subset of the sites/indexes that might use the integration
> module.  In this regard, I'm wondering if adding to the query (using
> the dismax or mlt handlers) a fq that matches all documents would have
> any impact on performance?  I gatehr that there is caching for the fq
> matches, but it seems liek that would still incur some overhead,
> especially for a large index?
>
> As a more concrete example, suppose each document has a string field
> that names the role of user that is allowed to see the content.  e.g.
> 'public', 'registered', 'admin'.  Most sites have only public content,
> but because our code is generic, we might add  &fq=role:public to
> every query.  What would the expected performance effect be compared
> to omitting that fq if, for example, we had a way to determine in
> advance that all site content matches 'public'.
>
> Thanks,
>
> Peter
>
> --
> Peter M. Wolanin, Ph.D.
> Momentum Specialist,  Acquia. Inc.
> peter.wolanin@acquia.com
>