gus-asf commented on code in PR #2596: URL: https://github.com/apache/solr/pull/2596#discussion_r1704117843
########## solr/CHANGES.txt: ########## @@ -103,7 +103,7 @@ Other Changes ================== 9.7.0 ================== New Features --------------------- -* SOLR-13350: Multithreaded search execution (Ishan Chattopadhyaya, Mark Miller, Christine Poerschke, David Smiley, noble) +* SOLR-13350, SOLR-17298: Opt-in multithreaded search execution (Ishan Chattopadhyaya, Mark Miller, Christine Poerschke, David Smiley, noble, Gus Heck) Review Comment: I think it's fine to leave it in as a feature for 2 reasons: 1) It's actively enabled/disabled by the user, and 2) This might affect how one thinks about sizing and sharding strategies. Previously on a cluster with a small to moderate sized index that isn't changing size quickly one might have added shards to be sure to take advantage of many cpu cores. Though I'm not sure if we expose it, one could now think of going single shard, multi-thread and limiting the segment size to ensure there are enough segments to fill up your cpu-cores... One could even think of trying a merge policy that targets maintaining a specific number of segments so that every search is fully utilizing the cores available (or utilizing a target fraction) on boxes with many cores? It's a performance thing, but it's not an invisible touch free performance thing, which is what I think of when I use the word optimization. -- 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
