Cache=false - cause the use-case requires distinct time ranges, no reuse.
When using fq: q is set to *:*.
Are there any alternatives for the grouping algorithm?
If not, is there a way to reuse filter results between 2 passes?
Thank you,
Esther
From:
Yonik Seeley <ysee...@gmail.com>
To:
"solr-user@lucene.apache.org" <solr-user@lucene.apache.org>
Cc:
Arnon Yogev/Haifa/IBM@IBMIL, Shai Erera/Haifa/IBM@IBMIL
Date:
25/06/2015 02:50 AM
Subject:
Re: fq versus q
Why is cache=false set for the filter?
Grouping uses a 2 pass algorithm by default, so that means that the
filter will need to be generated twice (I think) if caching is turned
off.
Also, when you try to use the "fq" version, what are you using for the
main query?
-Yonik
On Wed, Jun 24, 2015 at 7:28 AM, Esther Goldbraich
<estherg...@il.ibm.com> wrote:
> Hi,
>
> We are comparing the performance of fq versus q for queries that are
> actually filters and should not be cached.
> In part of queries we see strange behavior where q performs 5-10x better
> than fq. The question is why?
>
> An example1:
> q=maildate:{DATE1 to DATE2} COMPARED TO fq={!cache=false}maildate:{DATE1
> to DATE2}
> sort=maildate_sort* desc
> rows=50
> start=0
> group=true
> group.query=some query (without dates)
> group.query=*:*
> group.sort=maildate_sort desc
> additional fqs
>
> Schema:
> <field name="maildate" stored="true" indexed="true" type="tdate"/>
> <field name="maildate_sort" stored="false" indexed="false" type="tdate"
> docValues="true"/>
>
> Thank you,
> Esther
> -------------------------------------------------
> Esther Goldbraich
> Social Technologies & Analytics - IBM Haifa Research Lab
> Phone: +972-4-8281059
