Yonik,
Requesting
fl=unique_key:field(unique_key),secondary_key:field(secondary_key),score vs
fl=unique_key,secondary_key,score was a nice performance win, as unique_key
and secondary_key were both already in the fieldCache. We removed our
documentCache, in fact, as it got very such little use.
Yonik,
That's a very clever idea. Unfortunately, I think that will skip the
distributed query optimization we were hoping to take advantage of in
SOLR-1880 [1], but it should work with the proposed distrib.singlePass
optimization in SOLR-5768 [2]. Does that sound right?
--Gregg
[1]
On Mon, Mar 3, 2014 at 11:14 AM, Gregg Donovan gregg...@gmail.com wrote:
Yonik,
That's a very clever idea. Unfortunately, I think that will skip the
distributed query optimization we were hoping to take advantage of in
SOLR-1880 [1], but it should work with the proposed distrib.singlePass
You could try forcing things to go through function queries (via pseudo-fields):
fl=field(id), field(myfield)
If you're not requesting any stored fields, that *might* currently
skip that step.
-Yonik
http://heliosearch.org - native off-heap filters and fieldcache for solr
On Mon, Feb 24, 2014
I vaguely remember such a Jira issue but I can't find it now.
Gregg, can you open an issue? A patch would be even better.
On Tue, Feb 25, 2014 at 8:28 AM, Gregg Donovan gregg...@gmail.com wrote:
We fetch a large number of documents -- 1000+ -- for each search. Each
request fetches only the
We fetch a large number of documents -- 1000+ -- for each search. Each
request fetches only the uniqueKey or the uniqueKey plus one secondary
integer key. Despite this, we find that we spent a sizable amount of time
in SolrIndexSearcher#doc(int docId, SetString fields). Time is spent
fetching the
