Ah, I think you're misunderstanding the nature of post-filters.
Or I'm confused, which happens a lot!
The whole point of post filters is that they're assumed to be
expensive (think ACL calculation). So you want them to run
on the fewest documents possible. So only docs that make it
through the primary query _and_ all lower-cost filters will get
to this post-filter. This means they can't be cached for
instance, because they don't see (hopefully) very many docs.
This is radically different than normal fq clauses, which are
calculated on the entire corpus and can thus be cached.
Best,
Erick
On Wed, Oct 9, 2013 at 11:59 AM, Rohit Harchandani <rhar...@gmail.com> wrote:
> Hey,
> so the post filter logs the number of ids that it receives.
> With the above filter having cost=200, the post filter should have received
> the same number of ids as before ( when the filter was not present ).
> But that does not seem to be the case...with the filter query on the index,
> the number of ids that the post filter is receiving reduces.
>
> Thanks,
> Rohit
>
>
> On Tue, Oct 8, 2013 at 8:29 PM, Erick Erickson <erickerick...@gmail.com>wrote:
>
>> Hmmm, seems like it should. What's our evidence that it isn't working?
>>
>> Best,
>> Erick
>>
>> On Tue, Oct 8, 2013 at 4:10 PM, Rohit Harchandani <rhar...@gmail.com>
>> wrote:
>> > Hey,
>> > I am using solr 4.0 with my own PostFilter implementation which is
>> executed
>> > after the normal solr query is done. This filter has a cost of 100. Is it
>> > possible to run filter queries on the index after the execution of the
>> post
>> > filter?
>> > I tried adding the below line to the url but it did not seem to work:
>> > &fq={!cache=false cost=200}field:value
>> > Thanks,
>> > Rohit
>>
