Re: Filter queries & caching

[Erick Erickson]

So by adding =query to the
q=features:electronics&=name:samsung
I get these two bits back:

"parsedquery_toString":"features:electronics",
"parsed_filter_queries":["name:samsung"]}}

Which I do find a bit suprising, but I'd guess there's some
clever processing whereby the two && bits in
&= are interpreted just as a missing URL parameter.

Even so, the two queries wind up being exactly the same
in terms of scoring and the like.

And I'm not sure I'd depend on this parsing to work for all
query parsers

Best,
Erick




On Tue, Dec 20, 2016 at 7:04 AM, Alessandro Benedetti
 wrote:
> Hi Erick,
> just thinking on this :
>
> 1) "q=myclause AND filter(field:value)
>
> is identical to
>
> 2) q=myclause=field:value"
>
> Correct me if I am wrong,
> those two queries , from filter caching point of view are identical, but
> from scoring point of you :
>
> 1) will score only the documents resulting from the intersection
>
> 2) will score all the documents in myClause and then intersect with the not
> ordered docIds list coming from the filter query.
>
> Am I right ? I didn't take a look into the code, so I am just guessing,
> Cheers
>
> On Tue, May 10, 2016 at 4:30 PM, Erick Erickson 
> wrote:
>
>> No. Please re-read and use the admin plugins/stats page to examine for
>> yourself.
>>
>> 1)  fq=filter(fromfield:[* TO NOW/DAY+1DAY]&& tofield:[NOW/DAY-7DAY TO *])
>> && fq=type:abc
>>
>> && is totally unnecessary when using fq clauses, there is already an
>> implicit AND.
>> I'm not even sure what the above does, I don't quite know off the top of
>> my head
>> how that would be parsed.
>>
>> fq=filter() is unnecessary and in fact (apparently) uses extra
>> filterCache entries
>> to no purpose.
>>
>> I'm guessing you're thinking of something like this
>>
>> q=*:*=(fromfield:[* TO NOW/DAY+1DAY] && tofield:[NOW/DAY-7DAY TO
>> *])=type:abc
>>
>> Would use 2 filterCache entries,
>>
>> or maybe this: (notice this is "q=" not "fq=")
>>
>> q=filter(fromfield:[* TO NOW/DAY+1DAY] && tofield:[NOW/DAY-7DAY TO *])
>> && filter(type:abc)
>>
>> would use two filter queries as well. Same thing essentially.
>>
>> 2) fq= fromfield:[* TO NOW/DAY+1DAY]&& fq=tofield:[NOW/DAY-7DAY TO *]) &&
>> fq=type:abc
>>
>> This is syntactically incorrect, I assume you meant (added left paren
>> and again the && is unnecessary):
>>
>> q=*:*=(fromfield:[* TO NOW/DAY+1DAY] && fq=tofield:[NOW/DAY-7DAY TO *])&
>> fq=type:abc
>>
>> As above the rewritten form would use two filterCache entries.
>>
>> Best,
>> Erick
>>
>> On Mon, May 9, 2016 at 11:03 PM, Jay Potharaju 
>> wrote:
>> > Thanks for the explanation Eric.
>> >
>> > So that I understand this clearly
>> >
>> >
>> > 1)  fq=filter(fromfield:[* TO NOW/DAY+1DAY]&& tofield:[NOW/DAY-7DAY TO
>> *])
>> > && fq=type:abc
>> > 2) fq= fromfield:[* TO NOW/DAY+1DAY]&& fq=tofield:[NOW/DAY-7DAY TO *]) &&
>> > fq=type:abc
>> >
>> > Using 1) would benefit from having 2 separate filter caches instead of 3
>> > slots in the cache. But in general both would be using the filter cache.
>> > And secondly it would  be more useful to use filter() in a scenario like
>> > above(mentioned in your email).
>> > Thanks
>> >
>> >
>> >
>> >
>> > On Mon, May 9, 2016 at 9:43 PM, Erick Erickson 
>> > wrote:
>> >
>> >> You're confusing a query clause with fq when thinking about filter() I
>> >> think.
>> >>
>> >> Essentially they don't need to be used together, i.e.
>> >>
>> >> q=myclause AND filter(field:value)
>> >>
>> >> is identical to
>> >>
>> >> q=myclause=field:value
>> >>
>> >> both in docs returned and filterCache usage.
>> >>
>> >> q=myclause(fq=field:value)
>> >>
>> >> actually uses two filterCache entries, so is probably not what you want
>> to
>> >> use.
>> >>
>> >> the filter() syntax attached to a q clause (not an fq clause) is meant
>> >> to allow you to get speedups
>> >> you want to use compound clauses without having every combination be
>> >> separate filterCache entries.
>> >>
>> >> Consider the following:
>> >> fq=A OR B
>> >> fq=A AND B
>> >> fq=A
>> >> fq=B
>> >>
>> >> These would require 4 filterCache entries.
>> >>
>> >> q=filter(A) OR filter(B)
>> >> q=filter(A) AND filter(B)
>> >> q=filter(A)
>> >> q=filter(B)
>> >>
>> >> would only require two. Yet all of them would be satisfied only by
>> >> looking at the filterCache.
>> >>
>> >> Aside from the example immediately above, which one you use is largely
>> >> a matter of taste.
>> >>
>> >> Best,
>> >> Erick
>> >>
>> >> On Mon, May 9, 2016 at 12:47 PM, Jay Potharaju 
>> >> wrote:
>> >> > Thanks Ahmet...but I am not still clear how is adding filter() option
>> >> > better or is it the same as filtercache?
>> >> >
>> >> > My question is below.
>> >> >
>> >> > "As mentioned above adding filter() will add the filter query to the
>> >> cache.
>> >> > This would mean that results are fetched from cache instead of
>> running n
>> >> > 

Re: Filter queries & caching

[Alessandro Benedetti]

Hi Erick,
just thinking on this :

1) "q=myclause AND filter(field:value)

is identical to

2) q=myclause=field:value"

Correct me if I am wrong,
those two queries , from filter caching point of view are identical, but
from scoring point of you :

1) will score only the documents resulting from the intersection

2) will score all the documents in myClause and then intersect with the not
ordered docIds list coming from the filter query.

Am I right ? I didn't take a look into the code, so I am just guessing,
Cheers

On Tue, May 10, 2016 at 4:30 PM, Erick Erickson 
wrote:

> No. Please re-read and use the admin plugins/stats page to examine for
> yourself.
>
> 1)  fq=filter(fromfield:[* TO NOW/DAY+1DAY]&& tofield:[NOW/DAY-7DAY TO *])
> && fq=type:abc
>
> && is totally unnecessary when using fq clauses, there is already an
> implicit AND.
> I'm not even sure what the above does, I don't quite know off the top of
> my head
> how that would be parsed.
>
> fq=filter() is unnecessary and in fact (apparently) uses extra
> filterCache entries
> to no purpose.
>
> I'm guessing you're thinking of something like this
>
> q=*:*=(fromfield:[* TO NOW/DAY+1DAY] && tofield:[NOW/DAY-7DAY TO
> *])=type:abc
>
> Would use 2 filterCache entries,
>
> or maybe this: (notice this is "q=" not "fq=")
>
> q=filter(fromfield:[* TO NOW/DAY+1DAY] && tofield:[NOW/DAY-7DAY TO *])
> && filter(type:abc)
>
> would use two filter queries as well. Same thing essentially.
>
> 2) fq= fromfield:[* TO NOW/DAY+1DAY]&& fq=tofield:[NOW/DAY-7DAY TO *]) &&
> fq=type:abc
>
> This is syntactically incorrect, I assume you meant (added left paren
> and again the && is unnecessary):
>
> q=*:*=(fromfield:[* TO NOW/DAY+1DAY] && fq=tofield:[NOW/DAY-7DAY TO *])&
> fq=type:abc
>
> As above the rewritten form would use two filterCache entries.
>
> Best,
> Erick
>
> On Mon, May 9, 2016 at 11:03 PM, Jay Potharaju 
> wrote:
> > Thanks for the explanation Eric.
> >
> > So that I understand this clearly
> >
> >
> > 1)  fq=filter(fromfield:[* TO NOW/DAY+1DAY]&& tofield:[NOW/DAY-7DAY TO
> *])
> > && fq=type:abc
> > 2) fq= fromfield:[* TO NOW/DAY+1DAY]&& fq=tofield:[NOW/DAY-7DAY TO *]) &&
> > fq=type:abc
> >
> > Using 1) would benefit from having 2 separate filter caches instead of 3
> > slots in the cache. But in general both would be using the filter cache.
> > And secondly it would  be more useful to use filter() in a scenario like
> > above(mentioned in your email).
> > Thanks
> >
> >
> >
> >
> > On Mon, May 9, 2016 at 9:43 PM, Erick Erickson 
> > wrote:
> >
> >> You're confusing a query clause with fq when thinking about filter() I
> >> think.
> >>
> >> Essentially they don't need to be used together, i.e.
> >>
> >> q=myclause AND filter(field:value)
> >>
> >> is identical to
> >>
> >> q=myclause=field:value
> >>
> >> both in docs returned and filterCache usage.
> >>
> >> q=myclause(fq=field:value)
> >>
> >> actually uses two filterCache entries, so is probably not what you want
> to
> >> use.
> >>
> >> the filter() syntax attached to a q clause (not an fq clause) is meant
> >> to allow you to get speedups
> >> you want to use compound clauses without having every combination be
> >> separate filterCache entries.
> >>
> >> Consider the following:
> >> fq=A OR B
> >> fq=A AND B
> >> fq=A
> >> fq=B
> >>
> >> These would require 4 filterCache entries.
> >>
> >> q=filter(A) OR filter(B)
> >> q=filter(A) AND filter(B)
> >> q=filter(A)
> >> q=filter(B)
> >>
> >> would only require two. Yet all of them would be satisfied only by
> >> looking at the filterCache.
> >>
> >> Aside from the example immediately above, which one you use is largely
> >> a matter of taste.
> >>
> >> Best,
> >> Erick
> >>
> >> On Mon, May 9, 2016 at 12:47 PM, Jay Potharaju 
> >> wrote:
> >> > Thanks Ahmet...but I am not still clear how is adding filter() option
> >> > better or is it the same as filtercache?
> >> >
> >> > My question is below.
> >> >
> >> > "As mentioned above adding filter() will add the filter query to the
> >> cache.
> >> > This would mean that results are fetched from cache instead of
> running n
> >> > number of filter queries  in parallel.
> >> > Is it necessary to use the filter() option? I was under the impression
> >> that
> >> > all filter queries will get added to the "filtercache". What is the
> >> > advantage of using filter()?"
> >> >
> >> > Thanks
> >> >
> >> > On Sun, May 8, 2016 at 6:30 PM, Ahmet Arslan
> 
> >> > wrote:
> >> >
> >> >> Hi,
> >> >>
> >> >> As I understand it useful incase you use an OR operator between two
> >> >> restricting clauses.
> >> >> Recall that multiple fq means implicit AND.
> >> >>
> >> >> ahmet
> >> >>
> >> >>
> >> >>
> >> >> On Monday, May 9, 2016 4:02 AM, Jay Potharaju  >
> >> >> wrote:
> >> >> As mentioned above adding filter() will add the filter query to the
> >> cache.
> >> >> This 

Re: Filter queries & caching

[Erick Erickson]

No. Please re-read and use the admin plugins/stats page to examine for yourself.

1)  fq=filter(fromfield:[* TO NOW/DAY+1DAY]&& tofield:[NOW/DAY-7DAY TO *])
&& fq=type:abc

&& is totally unnecessary when using fq clauses, there is already an
implicit AND.
I'm not even sure what the above does, I don't quite know off the top of my head
how that would be parsed.

fq=filter() is unnecessary and in fact (apparently) uses extra
filterCache entries
to no purpose.

I'm guessing you're thinking of something like this

q=*:*=(fromfield:[* TO NOW/DAY+1DAY] && tofield:[NOW/DAY-7DAY TO
*])=type:abc

Would use 2 filterCache entries,

or maybe this: (notice this is "q=" not "fq=")

q=filter(fromfield:[* TO NOW/DAY+1DAY] && tofield:[NOW/DAY-7DAY TO *])
&& filter(type:abc)

would use two filter queries as well. Same thing essentially.

2) fq= fromfield:[* TO NOW/DAY+1DAY]&& fq=tofield:[NOW/DAY-7DAY TO *]) &&
fq=type:abc

This is syntactically incorrect, I assume you meant (added left paren
and again the && is unnecessary):

q=*:*=(fromfield:[* TO NOW/DAY+1DAY] && fq=tofield:[NOW/DAY-7DAY TO *])&
fq=type:abc

As above the rewritten form would use two filterCache entries.

Best,
Erick

On Mon, May 9, 2016 at 11:03 PM, Jay Potharaju  wrote:
> Thanks for the explanation Eric.
>
> So that I understand this clearly
>
>
> 1)  fq=filter(fromfield:[* TO NOW/DAY+1DAY]&& tofield:[NOW/DAY-7DAY TO *])
> && fq=type:abc
> 2) fq= fromfield:[* TO NOW/DAY+1DAY]&& fq=tofield:[NOW/DAY-7DAY TO *]) &&
> fq=type:abc
>
> Using 1) would benefit from having 2 separate filter caches instead of 3
> slots in the cache. But in general both would be using the filter cache.
> And secondly it would  be more useful to use filter() in a scenario like
> above(mentioned in your email).
> Thanks
>
>
>
>
> On Mon, May 9, 2016 at 9:43 PM, Erick Erickson 
> wrote:
>
>> You're confusing a query clause with fq when thinking about filter() I
>> think.
>>
>> Essentially they don't need to be used together, i.e.
>>
>> q=myclause AND filter(field:value)
>>
>> is identical to
>>
>> q=myclause=field:value
>>
>> both in docs returned and filterCache usage.
>>
>> q=myclause(fq=field:value)
>>
>> actually uses two filterCache entries, so is probably not what you want to
>> use.
>>
>> the filter() syntax attached to a q clause (not an fq clause) is meant
>> to allow you to get speedups
>> you want to use compound clauses without having every combination be
>> separate filterCache entries.
>>
>> Consider the following:
>> fq=A OR B
>> fq=A AND B
>> fq=A
>> fq=B
>>
>> These would require 4 filterCache entries.
>>
>> q=filter(A) OR filter(B)
>> q=filter(A) AND filter(B)
>> q=filter(A)
>> q=filter(B)
>>
>> would only require two. Yet all of them would be satisfied only by
>> looking at the filterCache.
>>
>> Aside from the example immediately above, which one you use is largely
>> a matter of taste.
>>
>> Best,
>> Erick
>>
>> On Mon, May 9, 2016 at 12:47 PM, Jay Potharaju 
>> wrote:
>> > Thanks Ahmet...but I am not still clear how is adding filter() option
>> > better or is it the same as filtercache?
>> >
>> > My question is below.
>> >
>> > "As mentioned above adding filter() will add the filter query to the
>> cache.
>> > This would mean that results are fetched from cache instead of running n
>> > number of filter queries  in parallel.
>> > Is it necessary to use the filter() option? I was under the impression
>> that
>> > all filter queries will get added to the "filtercache". What is the
>> > advantage of using filter()?"
>> >
>> > Thanks
>> >
>> > On Sun, May 8, 2016 at 6:30 PM, Ahmet Arslan 
>> > wrote:
>> >
>> >> Hi,
>> >>
>> >> As I understand it useful incase you use an OR operator between two
>> >> restricting clauses.
>> >> Recall that multiple fq means implicit AND.
>> >>
>> >> ahmet
>> >>
>> >>
>> >>
>> >> On Monday, May 9, 2016 4:02 AM, Jay Potharaju 
>> >> wrote:
>> >> As mentioned above adding filter() will add the filter query to the
>> cache.
>> >> This would mean that results are fetched from cache instead of running n
>> >> number of filter queries  in parallel.
>> >> Is it necessary to use the filter() option? I was under the impression
>> that
>> >> all filter queries will get added to the "filtercache". What is the
>> >> advantage of using filter()?
>> >>
>> >> *From
>> >> doc:
>> >>
>> https://cwiki.apache.org/confluence/display/solr/Query+Settings+in+SolrConfig
>> >> <
>> >>
>> https://cwiki.apache.org/confluence/display/solr/Query+Settings+in+SolrConfig
>> >> >*
>> >> This cache is used by SolrIndexSearcher for filters (DocSets) for
>> unordered
>> >> sets of all documents that match a query. The numeric attributes control
>> >> the number of entries in the cache.
>> >> Solr uses the filterCache to cache results of queries that use the fq
>> >> search parameter. Subsequent queries using the same parameter setting
>> >> result 

Re: Filter queries & caching

[Jay Potharaju]

Thanks for the explanation Eric.

So that I understand this clearly


1)  fq=filter(fromfield:[* TO NOW/DAY+1DAY]&& tofield:[NOW/DAY-7DAY TO *])
&& fq=type:abc
2) fq= fromfield:[* TO NOW/DAY+1DAY]&& fq=tofield:[NOW/DAY-7DAY TO *]) &&
fq=type:abc

Using 1) would benefit from having 2 separate filter caches instead of 3
slots in the cache. But in general both would be using the filter cache.
And secondly it would  be more useful to use filter() in a scenario like
above(mentioned in your email).
Thanks




On Mon, May 9, 2016 at 9:43 PM, Erick Erickson 
wrote:

> You're confusing a query clause with fq when thinking about filter() I
> think.
>
> Essentially they don't need to be used together, i.e.
>
> q=myclause AND filter(field:value)
>
> is identical to
>
> q=myclause=field:value
>
> both in docs returned and filterCache usage.
>
> q=myclause(fq=field:value)
>
> actually uses two filterCache entries, so is probably not what you want to
> use.
>
> the filter() syntax attached to a q clause (not an fq clause) is meant
> to allow you to get speedups
> you want to use compound clauses without having every combination be
> separate filterCache entries.
>
> Consider the following:
> fq=A OR B
> fq=A AND B
> fq=A
> fq=B
>
> These would require 4 filterCache entries.
>
> q=filter(A) OR filter(B)
> q=filter(A) AND filter(B)
> q=filter(A)
> q=filter(B)
>
> would only require two. Yet all of them would be satisfied only by
> looking at the filterCache.
>
> Aside from the example immediately above, which one you use is largely
> a matter of taste.
>
> Best,
> Erick
>
> On Mon, May 9, 2016 at 12:47 PM, Jay Potharaju 
> wrote:
> > Thanks Ahmet...but I am not still clear how is adding filter() option
> > better or is it the same as filtercache?
> >
> > My question is below.
> >
> > "As mentioned above adding filter() will add the filter query to the
> cache.
> > This would mean that results are fetched from cache instead of running n
> > number of filter queries  in parallel.
> > Is it necessary to use the filter() option? I was under the impression
> that
> > all filter queries will get added to the "filtercache". What is the
> > advantage of using filter()?"
> >
> > Thanks
> >
> > On Sun, May 8, 2016 at 6:30 PM, Ahmet Arslan 
> > wrote:
> >
> >> Hi,
> >>
> >> As I understand it useful incase you use an OR operator between two
> >> restricting clauses.
> >> Recall that multiple fq means implicit AND.
> >>
> >> ahmet
> >>
> >>
> >>
> >> On Monday, May 9, 2016 4:02 AM, Jay Potharaju 
> >> wrote:
> >> As mentioned above adding filter() will add the filter query to the
> cache.
> >> This would mean that results are fetched from cache instead of running n
> >> number of filter queries  in parallel.
> >> Is it necessary to use the filter() option? I was under the impression
> that
> >> all filter queries will get added to the "filtercache". What is the
> >> advantage of using filter()?
> >>
> >> *From
> >> doc:
> >>
> https://cwiki.apache.org/confluence/display/solr/Query+Settings+in+SolrConfig
> >> <
> >>
> https://cwiki.apache.org/confluence/display/solr/Query+Settings+in+SolrConfig
> >> >*
> >> This cache is used by SolrIndexSearcher for filters (DocSets) for
> unordered
> >> sets of all documents that match a query. The numeric attributes control
> >> the number of entries in the cache.
> >> Solr uses the filterCache to cache results of queries that use the fq
> >> search parameter. Subsequent queries using the same parameter setting
> >> result in cache hits and rapid returns of results. See Searching for a
> >> detailed discussion of the fq parameter.
> >>
> >> *From Yonik's site: http://yonik.com/solr/query-syntax/#FilterQuery
> >> *
> >>
> >> (Since Solr 5.4)
> >>
> >> A filter query retrieves a set of documents matching a query from the
> >> filter cache. Since scores are not cached, all documents that match the
> >> filter produce the same score (0 by default). Cached filters will be
> >> extremely fast when they are used again in another query.
> >>
> >>
> >> Thanks
> >>
> >>
> >> On Fri, May 6, 2016 at 9:46 AM, Jay Potharaju 
> >> wrote:
> >>
> >> > We have high query load and considering that I think the suggestions
> made
> >> > above will help with performance.
> >> > Thanks
> >> > Jay
> >> >
> >> > On Fri, May 6, 2016 at 7:26 AM, Shawn Heisey 
> >> wrote:
> >> >
> >> >> On 5/6/2016 7:19 AM, Shawn Heisey wrote:
> >> >> > With three separate
> >> >> > fq parameters, you'll get three cache entries in filterCache from
> the
> >> >> > one query.
> >> >>
> >> >> One more tidbit of information related to this:
> >> >>
> >> >> When you have multiple filters and they aren't cached, I am
> reasonably
> >> >> certain that they run in parallel.  Instead of one complex filter,
> you
> >> >> would have three simple filters running 

Re: Filter queries & caching

[Erick Erickson]

You're confusing a query clause with fq when thinking about filter() I think.

Essentially they don't need to be used together, i.e.

q=myclause AND filter(field:value)

is identical to

q=myclause=field:value

both in docs returned and filterCache usage.

q=myclause(fq=field:value)

actually uses two filterCache entries, so is probably not what you want to use.

the filter() syntax attached to a q clause (not an fq clause) is meant
to allow you to get speedups
you want to use compound clauses without having every combination be
separate filterCache entries.

Consider the following:
fq=A OR B
fq=A AND B
fq=A
fq=B

These would require 4 filterCache entries.

q=filter(A) OR filter(B)
q=filter(A) AND filter(B)
q=filter(A)
q=filter(B)

would only require two. Yet all of them would be satisfied only by
looking at the filterCache.

Aside from the example immediately above, which one you use is largely
a matter of taste.

Best,
Erick

On Mon, May 9, 2016 at 12:47 PM, Jay Potharaju  wrote:
> Thanks Ahmet...but I am not still clear how is adding filter() option
> better or is it the same as filtercache?
>
> My question is below.
>
> "As mentioned above adding filter() will add the filter query to the cache.
> This would mean that results are fetched from cache instead of running n
> number of filter queries  in parallel.
> Is it necessary to use the filter() option? I was under the impression that
> all filter queries will get added to the "filtercache". What is the
> advantage of using filter()?"
>
> Thanks
>
> On Sun, May 8, 2016 at 6:30 PM, Ahmet Arslan 
> wrote:
>
>> Hi,
>>
>> As I understand it useful incase you use an OR operator between two
>> restricting clauses.
>> Recall that multiple fq means implicit AND.
>>
>> ahmet
>>
>>
>>
>> On Monday, May 9, 2016 4:02 AM, Jay Potharaju 
>> wrote:
>> As mentioned above adding filter() will add the filter query to the cache.
>> This would mean that results are fetched from cache instead of running n
>> number of filter queries  in parallel.
>> Is it necessary to use the filter() option? I was under the impression that
>> all filter queries will get added to the "filtercache". What is the
>> advantage of using filter()?
>>
>> *From
>> doc:
>> https://cwiki.apache.org/confluence/display/solr/Query+Settings+in+SolrConfig
>> <
>> https://cwiki.apache.org/confluence/display/solr/Query+Settings+in+SolrConfig
>> >*
>> This cache is used by SolrIndexSearcher for filters (DocSets) for unordered
>> sets of all documents that match a query. The numeric attributes control
>> the number of entries in the cache.
>> Solr uses the filterCache to cache results of queries that use the fq
>> search parameter. Subsequent queries using the same parameter setting
>> result in cache hits and rapid returns of results. See Searching for a
>> detailed discussion of the fq parameter.
>>
>> *From Yonik's site: http://yonik.com/solr/query-syntax/#FilterQuery
>> *
>>
>> (Since Solr 5.4)
>>
>> A filter query retrieves a set of documents matching a query from the
>> filter cache. Since scores are not cached, all documents that match the
>> filter produce the same score (0 by default). Cached filters will be
>> extremely fast when they are used again in another query.
>>
>>
>> Thanks
>>
>>
>> On Fri, May 6, 2016 at 9:46 AM, Jay Potharaju 
>> wrote:
>>
>> > We have high query load and considering that I think the suggestions made
>> > above will help with performance.
>> > Thanks
>> > Jay
>> >
>> > On Fri, May 6, 2016 at 7:26 AM, Shawn Heisey 
>> wrote:
>> >
>> >> On 5/6/2016 7:19 AM, Shawn Heisey wrote:
>> >> > With three separate
>> >> > fq parameters, you'll get three cache entries in filterCache from the
>> >> > one query.
>> >>
>> >> One more tidbit of information related to this:
>> >>
>> >> When you have multiple filters and they aren't cached, I am reasonably
>> >> certain that they run in parallel.  Instead of one complex filter, you
>> >> would have three simple filters running simultaneously.  For low to
>> >> medium query loads on a server with a whole bunch of CPUs, where there
>> >> is plenty of spare CPU power, this can be a real gain in performance ...
>> >> but if the query load is really high, it might be a bad thing.
>> >>
>> >> Thanks,
>> >> Shawn
>> >>
>> >>
>> >
>> >
>> > --
>> > Thanks
>> > Jay Potharaju
>>
>> >
>> >
>>
>>
>>
>> --
>> Thanks
>> Jay Potharaju
>>
>
>
>
> --
> Thanks
> Jay Potharaju

Re: Filter queries & caching

[Jay Potharaju]

Thanks Ahmet...but I am not still clear how is adding filter() option
better or is it the same as filtercache?

My question is below.

"As mentioned above adding filter() will add the filter query to the cache.
This would mean that results are fetched from cache instead of running n
number of filter queries  in parallel.
Is it necessary to use the filter() option? I was under the impression that
all filter queries will get added to the "filtercache". What is the
advantage of using filter()?"

Thanks

On Sun, May 8, 2016 at 6:30 PM, Ahmet Arslan 
wrote:

> Hi,
>
> As I understand it useful incase you use an OR operator between two
> restricting clauses.
> Recall that multiple fq means implicit AND.
>
> ahmet
>
>
>
> On Monday, May 9, 2016 4:02 AM, Jay Potharaju 
> wrote:
> As mentioned above adding filter() will add the filter query to the cache.
> This would mean that results are fetched from cache instead of running n
> number of filter queries  in parallel.
> Is it necessary to use the filter() option? I was under the impression that
> all filter queries will get added to the "filtercache". What is the
> advantage of using filter()?
>
> *From
> doc:
> https://cwiki.apache.org/confluence/display/solr/Query+Settings+in+SolrConfig
> <
> https://cwiki.apache.org/confluence/display/solr/Query+Settings+in+SolrConfig
> >*
> This cache is used by SolrIndexSearcher for filters (DocSets) for unordered
> sets of all documents that match a query. The numeric attributes control
> the number of entries in the cache.
> Solr uses the filterCache to cache results of queries that use the fq
> search parameter. Subsequent queries using the same parameter setting
> result in cache hits and rapid returns of results. See Searching for a
> detailed discussion of the fq parameter.
>
> *From Yonik's site: http://yonik.com/solr/query-syntax/#FilterQuery
> *
>
> (Since Solr 5.4)
>
> A filter query retrieves a set of documents matching a query from the
> filter cache. Since scores are not cached, all documents that match the
> filter produce the same score (0 by default). Cached filters will be
> extremely fast when they are used again in another query.
>
>
> Thanks
>
>
> On Fri, May 6, 2016 at 9:46 AM, Jay Potharaju 
> wrote:
>
> > We have high query load and considering that I think the suggestions made
> > above will help with performance.
> > Thanks
> > Jay
> >
> > On Fri, May 6, 2016 at 7:26 AM, Shawn Heisey 
> wrote:
> >
> >> On 5/6/2016 7:19 AM, Shawn Heisey wrote:
> >> > With three separate
> >> > fq parameters, you'll get three cache entries in filterCache from the
> >> > one query.
> >>
> >> One more tidbit of information related to this:
> >>
> >> When you have multiple filters and they aren't cached, I am reasonably
> >> certain that they run in parallel.  Instead of one complex filter, you
> >> would have three simple filters running simultaneously.  For low to
> >> medium query loads on a server with a whole bunch of CPUs, where there
> >> is plenty of spare CPU power, this can be a real gain in performance ...
> >> but if the query load is really high, it might be a bad thing.
> >>
> >> Thanks,
> >> Shawn
> >>
> >>
> >
> >
> > --
> > Thanks
> > Jay Potharaju
>
> >
> >
>
>
>
> --
> Thanks
> Jay Potharaju
>



-- 
Thanks
Jay Potharaju

Re: Filter queries & caching

[Ahmet Arslan]

Hi,

As I understand it useful incase you use an OR operator between two restricting 
clauses.
Recall that multiple fq means implicit AND.

ahmet



On Monday, May 9, 2016 4:02 AM, Jay Potharaju  wrote:
As mentioned above adding filter() will add the filter query to the cache.
This would mean that results are fetched from cache instead of running n
number of filter queries  in parallel.
Is it necessary to use the filter() option? I was under the impression that
all filter queries will get added to the "filtercache". What is the
advantage of using filter()?

*From
doc: 
https://cwiki.apache.org/confluence/display/solr/Query+Settings+in+SolrConfig
*
This cache is used by SolrIndexSearcher for filters (DocSets) for unordered
sets of all documents that match a query. The numeric attributes control
the number of entries in the cache.
Solr uses the filterCache to cache results of queries that use the fq
search parameter. Subsequent queries using the same parameter setting
result in cache hits and rapid returns of results. See Searching for a
detailed discussion of the fq parameter.

*From Yonik's site: http://yonik.com/solr/query-syntax/#FilterQuery
*

(Since Solr 5.4)

A filter query retrieves a set of documents matching a query from the
filter cache. Since scores are not cached, all documents that match the
filter produce the same score (0 by default). Cached filters will be
extremely fast when they are used again in another query.


Thanks


On Fri, May 6, 2016 at 9:46 AM, Jay Potharaju  wrote:

> We have high query load and considering that I think the suggestions made
> above will help with performance.
> Thanks
> Jay
>
> On Fri, May 6, 2016 at 7:26 AM, Shawn Heisey  wrote:
>
>> On 5/6/2016 7:19 AM, Shawn Heisey wrote:
>> > With three separate
>> > fq parameters, you'll get three cache entries in filterCache from the
>> > one query.
>>
>> One more tidbit of information related to this:
>>
>> When you have multiple filters and they aren't cached, I am reasonably
>> certain that they run in parallel.  Instead of one complex filter, you
>> would have three simple filters running simultaneously.  For low to
>> medium query loads on a server with a whole bunch of CPUs, where there
>> is plenty of spare CPU power, this can be a real gain in performance ...
>> but if the query load is really high, it might be a bad thing.
>>
>> Thanks,
>> Shawn
>>
>>
>
>
> --
> Thanks
> Jay Potharaju

>
>



-- 
Thanks
Jay Potharaju

Re: Filter queries & caching

[Jay Potharaju]

As mentioned above adding filter() will add the filter query to the cache.
This would mean that results are fetched from cache instead of running n
number of filter queries  in parallel.
Is it necessary to use the filter() option? I was under the impression that
all filter queries will get added to the "filtercache". What is the
advantage of using filter()?

*From
doc: 
https://cwiki.apache.org/confluence/display/solr/Query+Settings+in+SolrConfig
*
This cache is used by SolrIndexSearcher for filters (DocSets) for unordered
sets of all documents that match a query. The numeric attributes control
the number of entries in the cache.
Solr uses the filterCache to cache results of queries that use the fq
search parameter. Subsequent queries using the same parameter setting
result in cache hits and rapid returns of results. See Searching for a
detailed discussion of the fq parameter.

*From Yonik's site: http://yonik.com/solr/query-syntax/#FilterQuery
*

(Since Solr 5.4)

A filter query retrieves a set of documents matching a query from the
filter cache. Since scores are not cached, all documents that match the
filter produce the same score (0 by default). Cached filters will be
extremely fast when they are used again in another query.


Thanks


On Fri, May 6, 2016 at 9:46 AM, Jay Potharaju  wrote:

> We have high query load and considering that I think the suggestions made
> above will help with performance.
> Thanks
> Jay
>
> On Fri, May 6, 2016 at 7:26 AM, Shawn Heisey  wrote:
>
>> On 5/6/2016 7:19 AM, Shawn Heisey wrote:
>> > With three separate
>> > fq parameters, you'll get three cache entries in filterCache from the
>> > one query.
>>
>> One more tidbit of information related to this:
>>
>> When you have multiple filters and they aren't cached, I am reasonably
>> certain that they run in parallel.  Instead of one complex filter, you
>> would have three simple filters running simultaneously.  For low to
>> medium query loads on a server with a whole bunch of CPUs, where there
>> is plenty of spare CPU power, this can be a real gain in performance ...
>> but if the query load is really high, it might be a bad thing.
>>
>> Thanks,
>> Shawn
>>
>>
>
>
> --
> Thanks
> Jay Potharaju
>
>



-- 
Thanks
Jay Potharaju

Re: Filter queries & caching

[Jay Potharaju]

We have high query load and considering that I think the suggestions made
above will help with performance.
Thanks
Jay

On Fri, May 6, 2016 at 7:26 AM, Shawn Heisey  wrote:

> On 5/6/2016 7:19 AM, Shawn Heisey wrote:
> > With three separate
> > fq parameters, you'll get three cache entries in filterCache from the
> > one query.
>
> One more tidbit of information related to this:
>
> When you have multiple filters and they aren't cached, I am reasonably
> certain that they run in parallel.  Instead of one complex filter, you
> would have three simple filters running simultaneously.  For low to
> medium query loads on a server with a whole bunch of CPUs, where there
> is plenty of spare CPU power, this can be a real gain in performance ...
> but if the query load is really high, it might be a bad thing.
>
> Thanks,
> Shawn
>
>


-- 
Thanks
Jay Potharaju

Re: Filter queries & caching

[Shawn Heisey]

On 5/6/2016 7:19 AM, Shawn Heisey wrote:
> With three separate
> fq parameters, you'll get three cache entries in filterCache from the
> one query.

One more tidbit of information related to this:

When you have multiple filters and they aren't cached, I am reasonably
certain that they run in parallel.  Instead of one complex filter, you
would have three simple filters running simultaneously.  For low to
medium query loads on a server with a whole bunch of CPUs, where there
is plenty of spare CPU power, this can be a real gain in performance ...
but if the query load is really high, it might be a bad thing.

Thanks,
Shawn

Re: Filter queries & caching

[Jay Potharaju]

Thanks Shawn,Erick & Ahmet , this was very helpful. 

> On May 6, 2016, at 6:19 AM, Shawn Heisey  wrote:
> 
>> On 5/5/2016 2:44 PM, Jay Potharaju wrote:
>> Are you suggesting rewriting it like this ?
>> fq=filter(fromfield:[* TO NOW/DAY+1DAY]&& tofield:[NOW/DAY-7DAY TO *] )
>> fq=filter(type:abc)
>> 
>> Is this a better use of the cache as supposed to fq=fromfield:[* TO
>> NOW/DAY+1DAY]&& tofield:[NOW/DAY-7DAY TO *] && type:"abc"
> 
> I keep writing emails and forgetting to send them.  Supplementing the
> excellent information you've already gotten:
> 
> Because all three clauses are ANDed together, what I would suggest doing
> is three filter queries:
> 
> fq=fromfield:[* TO NOW/DAY+1DAY]
> fq=tofield:[NOW/DAY-7DAY TO *]
> fq=type:abc
> 
> Whether or not to split your fq like this will depend on how you use
> filters, and how much memory you can let them use.  With three separate
> fq parameters, you'll get three cache entries in filterCache from the
> one query.  If the next query changes only one of those filters to
> something that's not in the cache yet, but leaves the other two alone,
> then Solr can get the results from the cache for two of them, and then
> will only need to run the query for one of them, saving time and system
> resources.
> 
> I removed the quotes from "abc" because for that specific example,
> quotes are not necessary.  For more complex information than abc, quotes
> might be important.  Experiment, and use what gets you the results you want.
> 
> Thanks,
> Shawn
> 

Re: Filter queries & caching

[Shawn Heisey]

On 5/5/2016 2:44 PM, Jay Potharaju wrote:
> Are you suggesting rewriting it like this ?
> fq=filter(fromfield:[* TO NOW/DAY+1DAY]&& tofield:[NOW/DAY-7DAY TO *] )
> fq=filter(type:abc)
>
> Is this a better use of the cache as supposed to fq=fromfield:[* TO
> NOW/DAY+1DAY]&& tofield:[NOW/DAY-7DAY TO *] && type:"abc"

I keep writing emails and forgetting to send them.  Supplementing the
excellent information you've already gotten:

Because all three clauses are ANDed together, what I would suggest doing
is three filter queries:

fq=fromfield:[* TO NOW/DAY+1DAY]
fq=tofield:[NOW/DAY-7DAY TO *]
fq=type:abc

Whether or not to split your fq like this will depend on how you use
filters, and how much memory you can let them use.  With three separate
fq parameters, you'll get three cache entries in filterCache from the
one query.  If the next query changes only one of those filters to
something that's not in the cache yet, but leaves the other two alone,
then Solr can get the results from the cache for two of them, and then
will only need to run the query for one of them, saving time and system
resources.

I removed the quotes from "abc" because for that specific example,
quotes are not necessary.  For more complex information than abc, quotes
might be important.  Experiment, and use what gets you the results you want.

Thanks,
Shawn

Re: Filter queries & caching

[Erick Erickson]

Well, first of all I would use separate fq clauses. IOW:
 fq=filter(fromfield:[* TO NOW/DAY+1DAY]&& tofield:[NOW/DAY-7DAY TO *]  &&
type:"abc")

would probably be better written as:
 fq=fromfield:[* TO NOW/DAY+1DAY]=tofield:[NOW/DAY-7DAY TO *]=type:"abc"

You can always spoof the * at the _end_ of the cache by putting it at
some date far in the
future, i.e.
fq=fromfield:[some-date TO NOW/DAY+1000DAYS]

But you can empirically figure this out, just go to the
admin>>core>>plugins/stats
and look at the hits for filterCache when you issue test queries.

Best,
Erick

On Thu, May 5, 2016 at 4:55 PM, Ahmet Arslan  wrote:
> Hi,
>
> It depends on your re-use patterns. Query supplied to the filter query (fq) 
> will be the key of the cache map. Subsequent filter query with an existing 
> key will be served from cache.
>
> For example lets say that you always use these two clauses together.
> Then it makes sense to use fq=+fromfield:[* TO NOW/DAY+1DAY] 
> +tofield:[NOW/DAY-7DAY TO *]
>
> If you have other requests where you filter on type, then separate it: 
> fq=type:abc
>
> It is beter to create smart cache keys that are likely to be issued again.
>
> If type:abc already restricts document space into a very small subset, then 
> you may use post filter option for the remaining restricting clauses.
>
> Ahmet
>
>
> On Friday, May 6, 2016 12:05 AM, Jay Potharaju  wrote:
> I have almost 50 million docs and growing ...that being said in a high
> query volume case does it make sense to use
>
> fq=filter(fromfield:[* TO NOW/DAY+1DAY]&& tofield:[NOW/DAY-7DAY TO *]  &&
> type:"abc")
>
> OR
> fq=filter(fromfield:[* TO NOW/DAY+1DAY]&& tofield:[NOW/DAY-7DAY TO *] )
> fq=filter(type:abc)
>
> Is this something that I would need to determine by running some test
> Thanks
>
> On Thu, May 5, 2016 at 1:44 PM, Jay Potharaju  wrote:
>
>> Are you suggesting rewriting it like this ?
>> fq=filter(fromfield:[* TO NOW/DAY+1DAY]&& tofield:[NOW/DAY-7DAY TO *] )
>> fq=filter(type:abc)
>>
>> Is this a better use of the cache as supposed to fq=fromfield:[* TO
>> NOW/DAY+1DAY]&& tofield:[NOW/DAY-7DAY TO *] && type:"abc"
>>
>> Thanks
>>
>> On Thu, May 5, 2016 at 12:50 PM, Ahmet Arslan 
>> wrote:
>>
>>> Hi,
>>>
>>> Cache enemy is not * but NOW. Since you round it to DAY, cache will work
>>> within-day.
>>> I would use separate filer queries, especially fq=type:abc for the
>>> structured query so it will be cached independently.
>>>
>>> Also consider disabling caching (using cost) in expensive queries:
>>> http://yonik.com/advanced-filter-caching-in-solr/
>>>
>>> Ahmet
>>>
>>>
>>>
>>> On Thursday, May 5, 2016 8:25 PM, Jay Potharaju 
>>> wrote:
>>> Hi,
>>> I have a filter query that gets  documents based on date ranges from last
>>> n
>>> days to anytime in future.
>>>
>>> The objective is to get documents between a date range, but the start date
>>> and end date values are stored in different fields and that is why I wrote
>>> the filter query as below
>>>
>>> fq=fromfield:[* TO NOW/DAY+1DAY]&& tofield:[NOW/DAY-7DAY TO *] &&
>>> type:"abc"
>>>
>>> The way these queries are currently written I think wont leverage the
>>> filter cache because of "*". Is there a better way to write this query so
>>> that I can leverage the cache.
>>>
>>>
>>>
>>> --
>>> Thanks
>>> Jay
>
>>>
>>
>>
>>
>> --
>> Thanks
>> Jay Potharaju
>>
>>
>
>
>
> --
> Thanks
> Jay Potharaju

Re: Filter queries & caching

[Ahmet Arslan]

Hi,

It depends on your re-use patterns. Query supplied to the filter query (fq) 
will be the key of the cache map. Subsequent filter query with an existing key 
will be served from cache.

For example lets say that you always use these two clauses together.
Then it makes sense to use fq=+fromfield:[* TO NOW/DAY+1DAY] 
+tofield:[NOW/DAY-7DAY TO *]

If you have other requests where you filter on type, then separate it: 
fq=type:abc

It is beter to create smart cache keys that are likely to be issued again.

If type:abc already restricts document space into a very small subset, then you 
may use post filter option for the remaining restricting clauses. 

Ahmet


On Friday, May 6, 2016 12:05 AM, Jay Potharaju  wrote:
I have almost 50 million docs and growing ...that being said in a high
query volume case does it make sense to use

fq=filter(fromfield:[* TO NOW/DAY+1DAY]&& tofield:[NOW/DAY-7DAY TO *]  &&
type:"abc")

OR
fq=filter(fromfield:[* TO NOW/DAY+1DAY]&& tofield:[NOW/DAY-7DAY TO *] )
fq=filter(type:abc)

Is this something that I would need to determine by running some test
Thanks

On Thu, May 5, 2016 at 1:44 PM, Jay Potharaju  wrote:

> Are you suggesting rewriting it like this ?
> fq=filter(fromfield:[* TO NOW/DAY+1DAY]&& tofield:[NOW/DAY-7DAY TO *] )
> fq=filter(type:abc)
>
> Is this a better use of the cache as supposed to fq=fromfield:[* TO
> NOW/DAY+1DAY]&& tofield:[NOW/DAY-7DAY TO *] && type:"abc"
>
> Thanks
>
> On Thu, May 5, 2016 at 12:50 PM, Ahmet Arslan 
> wrote:
>
>> Hi,
>>
>> Cache enemy is not * but NOW. Since you round it to DAY, cache will work
>> within-day.
>> I would use separate filer queries, especially fq=type:abc for the
>> structured query so it will be cached independently.
>>
>> Also consider disabling caching (using cost) in expensive queries:
>> http://yonik.com/advanced-filter-caching-in-solr/
>>
>> Ahmet
>>
>>
>>
>> On Thursday, May 5, 2016 8:25 PM, Jay Potharaju 
>> wrote:
>> Hi,
>> I have a filter query that gets  documents based on date ranges from last
>> n
>> days to anytime in future.
>>
>> The objective is to get documents between a date range, but the start date
>> and end date values are stored in different fields and that is why I wrote
>> the filter query as below
>>
>> fq=fromfield:[* TO NOW/DAY+1DAY]&& tofield:[NOW/DAY-7DAY TO *] &&
>> type:"abc"
>>
>> The way these queries are currently written I think wont leverage the
>> filter cache because of "*". Is there a better way to write this query so
>> that I can leverage the cache.
>>
>>
>>
>> --
>> Thanks
>> Jay

>>
>
>
>
> --
> Thanks
> Jay Potharaju
>
>



-- 
Thanks
Jay Potharaju

Re: Filter queries & caching

[Jay Potharaju]

I have almost 50 million docs and growing ...that being said in a high
query volume case does it make sense to use

 fq=filter(fromfield:[* TO NOW/DAY+1DAY]&& tofield:[NOW/DAY-7DAY TO *]  &&
type:"abc")

OR
fq=filter(fromfield:[* TO NOW/DAY+1DAY]&& tofield:[NOW/DAY-7DAY TO *] )
fq=filter(type:abc)

Is this something that I would need to determine by running some test
Thanks

On Thu, May 5, 2016 at 1:44 PM, Jay Potharaju  wrote:

> Are you suggesting rewriting it like this ?
> fq=filter(fromfield:[* TO NOW/DAY+1DAY]&& tofield:[NOW/DAY-7DAY TO *] )
> fq=filter(type:abc)
>
> Is this a better use of the cache as supposed to fq=fromfield:[* TO
> NOW/DAY+1DAY]&& tofield:[NOW/DAY-7DAY TO *] && type:"abc"
>
> Thanks
>
> On Thu, May 5, 2016 at 12:50 PM, Ahmet Arslan 
> wrote:
>
>> Hi,
>>
>> Cache enemy is not * but NOW. Since you round it to DAY, cache will work
>> within-day.
>> I would use separate filer queries, especially fq=type:abc for the
>> structured query so it will be cached independently.
>>
>> Also consider disabling caching (using cost) in expensive queries:
>> http://yonik.com/advanced-filter-caching-in-solr/
>>
>> Ahmet
>>
>>
>>
>> On Thursday, May 5, 2016 8:25 PM, Jay Potharaju 
>> wrote:
>> Hi,
>> I have a filter query that gets  documents based on date ranges from last
>> n
>> days to anytime in future.
>>
>> The objective is to get documents between a date range, but the start date
>> and end date values are stored in different fields and that is why I wrote
>> the filter query as below
>>
>> fq=fromfield:[* TO NOW/DAY+1DAY]&& tofield:[NOW/DAY-7DAY TO *] &&
>> type:"abc"
>>
>> The way these queries are currently written I think wont leverage the
>> filter cache because of "*". Is there a better way to write this query so
>> that I can leverage the cache.
>>
>>
>>
>> --
>> Thanks
>> Jay
>>
>
>
>
> --
> Thanks
> Jay Potharaju
>
>



-- 
Thanks
Jay Potharaju

Re: Filter queries & caching

[Jay Potharaju]

Are you suggesting rewriting it like this ?
fq=filter(fromfield:[* TO NOW/DAY+1DAY]&& tofield:[NOW/DAY-7DAY TO *] )
fq=filter(type:abc)

Is this a better use of the cache as supposed to fq=fromfield:[* TO
NOW/DAY+1DAY]&& tofield:[NOW/DAY-7DAY TO *] && type:"abc"

Thanks

On Thu, May 5, 2016 at 12:50 PM, Ahmet Arslan 
wrote:

> Hi,
>
> Cache enemy is not * but NOW. Since you round it to DAY, cache will work
> within-day.
> I would use separate filer queries, especially fq=type:abc for the
> structured query so it will be cached independently.
>
> Also consider disabling caching (using cost) in expensive queries:
> http://yonik.com/advanced-filter-caching-in-solr/
>
> Ahmet
>
>
>
> On Thursday, May 5, 2016 8:25 PM, Jay Potharaju 
> wrote:
> Hi,
> I have a filter query that gets  documents based on date ranges from last n
> days to anytime in future.
>
> The objective is to get documents between a date range, but the start date
> and end date values are stored in different fields and that is why I wrote
> the filter query as below
>
> fq=fromfield:[* TO NOW/DAY+1DAY]&& tofield:[NOW/DAY-7DAY TO *] &&
> type:"abc"
>
> The way these queries are currently written I think wont leverage the
> filter cache because of "*". Is there a better way to write this query so
> that I can leverage the cache.
>
>
>
> --
> Thanks
> Jay
>



-- 
Thanks
Jay Potharaju

Re: Filter queries & caching

[Ahmet Arslan]

Hi,

Cache enemy is not * but NOW. Since you round it to DAY, cache will work 
within-day.
I would use separate filer queries, especially fq=type:abc for the structured 
query so it will be cached independently.

Also consider disabling caching (using cost) in expensive queries:
http://yonik.com/advanced-filter-caching-in-solr/

Ahmet



On Thursday, May 5, 2016 8:25 PM, Jay Potharaju  wrote:
Hi,
I have a filter query that gets  documents based on date ranges from last n
days to anytime in future.

The objective is to get documents between a date range, but the start date
and end date values are stored in different fields and that is why I wrote
the filter query as below

fq=fromfield:[* TO NOW/DAY+1DAY]&& tofield:[NOW/DAY-7DAY TO *] && type:"abc"

The way these queries are currently written I think wont leverage the
filter cache because of "*". Is there a better way to write this query so
that I can leverage the cache.



-- 
Thanks
Jay

Filter queries & caching

[Jay Potharaju]

Hi,
I have a filter query that gets  documents based on date ranges from last n
days to anytime in future.

The objective is to get documents between a date range, but the start date
and end date values are stored in different fields and that is why I wrote
the filter query as below

fq=fromfield:[* TO NOW/DAY+1DAY]&& tofield:[NOW/DAY-7DAY TO *] && type:"abc"

The way these queries are currently written I think wont leverage the
filter cache because of "*". Is there a better way to write this query so
that I can leverage the cache.



-- 
Thanks
Jay