Hi Em, I briefly read the thread. Are you talking about combing of cached clauses of BooleanQuery, instead of evaluating whole BQ as a filter?
I found something like that in API (but only in API) http://lucene.apache.org/solr/api/org/apache/solr/search/ExtendedQuery.html#setCacheSep(boolean) Am I get you right? Why do you need it, btw? If I'm .. I have idea how to do it in two mins: q=+f:text +(_query_:{!fq}id:1 _query_:{!fq}id:2 _query_:{!fq}id:3 _query_:{!fq}id:4)... Right leg will be a BooleanQuery with SHOULD clauses backed on cached queries (see below). if you are not scarred by the syntax yet you can implement trivial "fq"QParserPlugin, which will be just // lazily through User/Generic Cache q = new FilteredQuery (new MatchAllDocsQuery(), new CachingWrapperFilter(new QueryWrapperFilter(subQuery(localParams.get(QueryParsing.V))))); return q; it will use per segment bitset at contrast to Solr's fq which caches for top level reader. WDYT? On Mon, Feb 13, 2012 at 11:34 PM, Em <[email protected]> wrote: > Hi, > > have a look at: > http://search-lucene.com/m/Z8lWGEiKoI > > I think not much had changed since then. > > Regards, > Em > > Am 13.02.2012 20:17, schrieb [email protected]: > > Hi, > > > > how efficent is such an query: > > > > q=some text > > fq=id:(1 OR 2 OR 3...) > > > > Should I better use q:some text AND id:(1 OR 2 OR 3...)? > > > > Is the Filter Cache used for the OR'ed fq? > > > > Thank you > > > > > -- Sincerely yours Mikhail Khludnev Lucid Certified Apache Lucene/Solr Developer Grid Dynamics <http://www.griddynamics.com> <[email protected]>
