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