I’m on Solr 8.10.1 and having a performance problem with my cross-core join
facets.
Here’s my basic query, with the interesting parts bolded (the joins in two
facet.query fields)
curl "$URL" --silent --show-error \
-X POST \
-F "q=($word AND -parent_tracings:($word))" \
-F 'df=title_tracings_t' \
-F 'fl=flrid,nodeid' \
\
-F 'fq=((grouping:"1" OR grouping:"2" OR grouping:"3") OR solrtype:"N")' \
-F 'fq={!tag=grouping}((grouping:"1" OR grouping:"2") OR solrtype:"N")' \
-F 'fq={!tag=languagecode}(languagecode:"eng" OR solrtype:"N")' \
-F 'fq=(tw_searchable:"Y")' \
-F 'facet=on' \
-F "facet.query=(solrtype:T AND !{!join fromIndex=collmatchagg from=flrid
to=flrid}id:$ID)" \
-F "facet.query=(solrtype:T AND {!join fromIndex=collmatchagg from=flrid
to=flrid}id:$ID)" \
-F 'rows=0' \
-F 'wt=json' \
-F 'debugQuery=on’ \
The faceting works wonderfully, except for when I make a commit to the
collmatchagg core, the “to” core in the facet. The first query we make after a
commit blocks for multiple seconds, depending on how many records are in the
core. With 10,000 records, which is standard load, that blocking is about 8-9
seconds, which is too long. If it’s only 1ten records in the core, the
blocking is about 1 second.
Here are some things I’ve observed about these slow first queries after a
commit:
* I’ve tried many different combinations of autowarmCount in the caching for
collmatchagg, from 0 to do no warming, to 100 to pull in a minimal number of
records. Changing these settings does not seem to have any impact on the
length of the block.
* If q=… in the query matches nothing, then the join is not slow.
* Making a direct query against collmatchagg is not slow after the commit.
* The only thing that seems to control the length of the block on the query is
the number of records in the collmatchagg core. It feels like Solr is reading
the entire core into RAM each time.
Any suggestions or pointers would be helpful, because this is blocking us from
releasing the feature.
Thanks,
Andy
