[prev in list] [next in list] [prev in thread] [next in thread] 

List:       solr-user
Subject:    Re: How to improve the Solr "OR" query performance
From:       Otis Gospodnetic <otis.gospodnetic () gmail ! com>
Date:       2013-07-03 16:10:40
Message-ID: CANNBgPLOOkwoX6xu8YrOH80ZWYmGwMN5XK0OzWXr+x688y-cKA () mail ! gmail ! com
[Download RAW message or body]

Hi,

Does that OR query need to be scored?
Does it repeat?
If answers are no and yes, you should use fq, not q.

Otis
--
Solr & ElasticSearch Support -- http://sematext.com/
Performance Monitoring -- http://sematext.com/spm



On Wed, Jul 3, 2013 at 12:07 PM, Kevin Osborn <kevin.osborn@cbsi.com> wrote:
> Also, what is the total document count for your result set? We have an
> application that is also very slow because it does a lot or OR queries. The
> problem is that the result set is very large because of the ORs. Profiling
> showed that Solr was spending the bulk of its time scoring the documents.
>
> Also, instead of OR, you may want to look at dismax or edismax. For search
> box type applications, OR is not really what you want. It just seems like
> what you want.
>
> -Kevin
>
>
> On Wed, Jul 3, 2013 at 5:10 AM, Toke Eskildsen <te@statsbiblioteket.dk>wrote:
>
>> On Wed, 2013-07-03 at 05:48 +0200, huasanyelao wrote:
>> > The response time for "OR" query is around 1-2seconds(the "AND" query is
>> just about 30ms-40ms ).
>>
>> The number of hits will also be much lower for the AND-query. To check
>> whether it is the OR or the size of the result set that is the problem,
>> please try and construct an AND-based query that hits about as many
>> documents as your slow OR query.
>>
>> With an index size of just 9GB, I am surprised that you use sharding.
>> Have you tried using just a single instance to avoid the merge-overhead?
>>
>> - Toke Eskildsen, State and University Library, Denmark
>>
>>
>
>
> --
> *KEVIN OSBORN*
> LEAD SOFTWARE ENGINEER
> CNET Content Solutions
> OFFICE 949.399.8714
> CELL 949.310.4677      SKYPE osbornk
> 5 Park Plaza, Suite 600, Irvine, CA 92614
> [image: CNET Content Solutions]
[prev in list] [next in list] [prev in thread] [next in thread]