dsmiley commented on PR #1360:
URL: https://github.com/apache/solr/pull/1360#issuecomment-1454873263

   I'll be sad to see the Terms caching go in SlowCompositeReaderWrapper but 
maybe it has to be this way.  Although I added the test of this, removed here, 
the underlying caching pre-dated me (hiding in MultiFields) in Lucene and I 
don't recall when it was added.  I [asked in 
Lucene](https://github.com/apache/lucene/pull/11998#issuecomment-1454862916) 
about the change which brought about the new assertion which prompted reverting 
this caching.  I don't like the idea of adding more thread-locals as a 
work-around.  Instead, maybe Solr can avoid some uses of 
SlowCompositeReaderWrapper where terms is used and retain reasonable 
performance?  I'm thinking of JoinUtils which could change its algorithm to 
loop over the leaves instead of assuming one leaf.  For another issue; it's too 
complicated / exploratory to be in this PR.  There are uses elsewhere too like 
in Collapsing when top_fc is used.  BTW SlowCompositeReaderWrapper is named 
this on purpose so that people don't use it ;-)
   
   Ideally we'd have some benchmark somewhere that uses join queries.  I know 
@gerlowskija and @joel-bernstein have worked on such as I've code-reviewed 
related things from them.  They are probably proprietary / not readily 
available but doesn't hurt to ping them :-).  After this change merges, we 
could broadcast to the users list that there is a change that maybe has a perf 
regression, inviting users to test it for themselves soon.  
https://hub.docker.com/r/apache/solr-nightly/tags


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org

Reply via email to