ok, we were able to confirm the behavior regarding not caching the filter
query. It works as expected. It does not cache with {!cache=false}.
We are still looking into clarifying the cost assignment: i.e. whether it
works as expected for long boolean filter queries.
On Tue, Dec 3, 2013 at 8:55 AM, Dmitry Kan <solrexp...@gmail.com> wrote:
> Hello!
>
> We have been experimenting with post filtering lately. Our setup is a
> filter having long boolean query; drawing the example from the Dublin's
> Stump the Chump:
>
> fq=UserId:(user1 OR user2 OR...OR user1000)
>
> The underlining issue impacting performance is that the combination of
> user ids in the query above is unique per each user in the system and on
> top the combination is changing every day.
>
> Our idea was to stop caching the filter query with {!cache=false}. Since
> there is no way to introspect the contents of the filter cache to our
> knowledge (jmx?), we can't be sure those are not cached. This is because
> the initial query per each combination takes substantially more time (as if
> it was *not* cached) than the second and subsequent queries with the same
> fq (as if it *was* cached).
>
> Question is: does post filtering support boolean queries in fq params?
>
> Another thing we have been trying is assigning a cost to the fq relatively
> higher than for other filter queries. Does this feature support the boolean
> queries in fq params as well?
>
> --
> Dmitry
> Blog: http://dmitrykan.blogspot.com
> Twitter: twitter.com/dmitrykan
>
--
Dmitry
Blog: http://dmitrykan.blogspot.com
Twitter: twitter.com/dmitrykan
