Rohit:
Ah, ok. I think Jim nailed it. The whole idea of post filters though,
is to use them when the filter is expensive. Do you have evidence
that the fq you're trying to use as a post-filter is "expensive"? I.e.
&fq={!cache=false cost=200}field:value takes time? Or are you
doing something in your post-filter that requires access to the
docs before the cost=200 field is applied?
Because the end result set is the same, the docs have to make it
through _all_ the fq clauses to be returned since you can
think of fq clauses as intersections.
Best,
Erick
On Wed, Oct 9, 2013 at 6:18 PM, jim ferenczi <jim.feren...@gmail.com> wrote:
> Hi Rohit,
> The main problem is that if the query inside the filter does not have a
> PostFilter implementation then your post filter is silently transformed
> into a simple filter. The query "field:value" is based on the inverted
> lists and does not have a postfilter support.
> If your field is a numeric field take a look at the frange query parser
> which has post filter support:
> To filter out document with a field value less than 5:
> fq={!frange l=5 cache=false cost=200}field(myField)
>
> Cheers,
> Jim
>
>
> 2013/10/9 Rohit Harchandani <rhar...@gmail.com>
>
>> yes i get that. actually i should have explained in more detail.
>>
>> - i have a query which gets certain documents.
>> - the post filter gets these matched documents and does some processing on
>> them and filters the results.
>> - but after this is done i need to apply another filter - which is why i
>> gave a higher cost to it.
>>
>> the reason i need to do this is because the processing done by the post
>> filter depends on the documents matching the query till that point.
>> since the normal fq clause is also getting executed before the post filter
>> (despite the cost), the final results are not accurate
>>
>> thanks
>> Rohit
>>
>>
>>
>>
>> On Wed, Oct 9, 2013 at 4:14 PM, Erick Erickson <erickerick...@gmail.com
>> >wrote:
>>
>> > 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
>> > >>
>> >
>>
