Update Vector Collection Search Tuning w.r.t. hz:query (6.x) [AI-215] (…

…#1340)

Updates the advice on what pool size should be used for `hz:query` if
optimising for search.

See
https://hazelcast.atlassian.net/wiki/spaces/CTO/pages/5400559722/Vector+Collection+Search+THPT+vs.+CPU+Usage
for more.

---------

Co-authored-by: Amanda Lindsay <[email protected]>

docs/modules/data-structures/pages/vector-search-overview.adoc

@@ -236,7 +236,7 @@ To decrease pressure on heap memory, you can decrease the number of parallel mig
 
 1. For searches with small `topK` (for example, 10) it may be beneficial to artificially increase `topK`, adjust `partitionLimit` accordingly, and discard extra results. If you need 10 results, a good starting point for tuning could be `topK=100` and a `partitionLimit` between 50 and 100. While this will make the search slower, it will also improve quality, sometimes significantly. Overall, this setup can be more efficient than increasing index build parameters (`max-degree`, `ef-construction`) which results in slower index builds and searches. With a very small `topK` or `paritionLimit`, the search algorithm is less able to escape local minima and find the best results.
 2. Vector deduplication does not incur significant overhead for uploads (usually less than 1%) and searches. You may consider disabling it to get slightly better performance and smaller memory usage if your dataset does not contain duplicated vectors. However, be aware that in the presence of many duplicated vectors with deduplication disabled, a  similarity search may return poor quality results.
-3. For a given query, each vector index partition is searched by 1 thread. The number of concurrent partition searches is configured by specifying a pool size for `hz:query` executor, which by default has 16 threads per member. In configurations with many cores, it can be increased to fully utilize all available cores as follows:
+3. For a given query, each vector index partition is searched by 1 thread. The number of concurrent partition searches is configured by specifying a pool size for `hz:query` executor, which by default has 16 threads per member. If optimizing for search, we recommend setting the `hz:query` pool size to be that of the physical core count of your host machines: this will result in a good balance between search throughput and CPU utilization. Setting `hz:query` to have a pool size greater than that of the physical core count will not deliver a significant increase in throughput but it will increase total CPU utilization. The `hz:query` pool size can be changed as follows:
 +
 [tabs] 
 ====