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
> > >>
> >
>
