Filter queries are a set of bits which is ANDed against query results at a very early stage of query processing. They are very useful. Note that they are stored (I think) in parsed query order, so you have to pass in the same filter query string each time.
On Mon, Oct 25, 2010 at 8:59 AM, Dennis Gearon <gear...@sbcglobal.net> wrote: > Thanks for that insight, a lot. > > Dennis Gearon > > Signature Warning > ---------------- > It is always a good idea to learn from your own mistakes. It is usually a > better idea to learn from others’ mistakes, so you do not have to make them > yourself. from > 'http://blogs.techrepublic.com.com/security/?p=4501&tag=nl.e036' > > EARTH has a Right To Life, > otherwise we all die. > > > --- On Mon, 10/25/10, Jonathan Rochkind <rochk...@jhu.edu> wrote: > >> From: Jonathan Rochkind <rochk...@jhu.edu> >> Subject: Re: Modelling Access Control >> To: "solr-user@lucene.apache.org" <solr-user@lucene.apache.org> >> Date: Monday, October 25, 2010, 8:19 AM >> Dennis Gearon wrote: >> > why use filter queries? >> > >> > Wouldn't reducing the set headed into the filters by >> putting it in the main query be faster? (A question to >> learn, since I do NOT know :-) >> > >> > >> No. At least as I understand it. In the best case, the >> filter query will be a lot faster, because filter queries >> are cached seperately in the filter cache. So if the >> existing filter query can be found in the cache, it'll be a >> lot faster. If it's not in the cache, the performance should >> be pretty much the same as if you had included it as an >> additional clause in the main q query. >> >> The reasons to put it in a fq filter are: >> >> 1) The caching behavior. You can have that certain part of >> the query be cached on it's own, speeding up any subsequent >> queries that use that same fq. >> >> 2) Simplification of client code. You can leave your 'q' >> however you want it, using whatever kind of query parser you >> want too (dismax, whatever), and just add on the 'fq' >> without touching the 'q'. This is a lot >> easier to do, and especially when you're using it for access >> control like this, a lot harder for a bug to creep in. >> >> Jonathan >> >> >> > -- Lance Norskog goks...@gmail.com
