On Tue, Feb 14, 2012 at 11:13 PM, Em <mailformailingli...@yahoo.de> wrote:
> Hi Mikhail,
>
> > it will use per segment bitset at contrast to Solr's fq which caches for
> > top level reader.
> Could you explain why this bitset would be per-segment based, please?
I don't see a reason why this *have* to be so.
>
it's just how org.apache.lucene.search.CachingWrapperFilter works. The
first out-of-the box stuff which I've found.
as an top-level segment alternative we need
org.apache.solr.search.SolrIndexSearcher.getDocSet(Query).
btw, one more top-level snippet
class FQParser extends QParser{
Query parse(...){
return new SolrConstantScoreQuery(
solrIndexSearcher.getDocSet(
subQuery(localParam.get(V))
).getTopFilter())
}
}
> What is the benefit you are seeing?
>
It seems like two different POVs: Lucene prefer per segment caching to
have fast incremental updates, but maybe 'because it's good but not in
worst case' (I guess I've heard it there
http://www.lucidimagination.com/devzone/events/conferences/ApacheLuceneEurocon2011/many-facets-apache-solr)
Solr prefer top-reader caches.
> Kind regards,
> Em
>
> Am 14.02.2012 19:33, schrieb Mikhail Khludnev:
> > 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 <mailformailingli...@yahoo.de>
> 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 spr...@gmx.eu:
> >>> 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>
<mkhlud...@griddynamics.com>
