[Question/Enhancement] Unconditional force-merge compaction in Milvus client `_optimize()` may be too costly and non-reproducible at 100M scale (LAION-100M)

Summary

In the Milvus client, _optimize() unconditionally triggers a force-merge compaction
before search for all non-GPU index types:

https://github.com/zilliztech/VectorDBBench/blob/main/vectordb_bench/backend/clients/milvus/milvus.py#L312-L316

MILVUS_FORCE_MERGE_TARGET_SIZE_MB = ((1 << 63) - 1) // (1024**2)   # line 21
...
self._wait_for_segments_sorted()
self._wait_for_index()
compaction_id = self.client.compact(
    self.collection_name, target_size=MILVUS_FORCE_MERGE_TARGET_SIZE_MB
)

Concerns at LAION-100M scale
I'd like to ask whether this is intended to run at 100M-vector scale (e.g. the
Performance768D100M / LAION-100M case), and whether it should be made configurable.

LAION-100M is 100M × 768-dim float32 ≈ 307 GB of raw vector data.

• Compaction cost: force merge rewrites the segments; at 300 GB+ this is a very long,
  IO/CPU-heavy operation on DataNodes. _optimize() is supposed to be a "prepare for
  search" step, but here it becomes a multi-hour data rewrite.
• Index rebuild memory: after merging into much larger segments, the vector index is
  rebuilt per segment. Index construction memory scales with segment size, so very large
  merged segments raise real OOM risk on the index/data node — especially for
  memory-hungry builds (HNSW, DiskANN).

Questions
1、Was unconditional force merge validated on the 100M-scale cases, and if so, what was
the observed compaction duration and peak DataNode / IndexNode memory?
2、Is the intent to normalize segment layout for fair comparison? If yes, wouldn't an
explicit, fixed target_size be more reproducible than the memory-dependent auto mode?

Start with vectordb_bench/backend/clients/milvus/milvus.py, especially MILVUS_FORCE_MERGE_TARGET_SIZE_MB near line 21 and _optimize() near lines 312-316. Trace the benchmark paths for Performance768D100M and LAION-100M, then gather the requested compaction-duration and peak-memory evidence. Done should be a maintainer-approved resolution for the force-merge behavior and its reproducibility or configurability at large scale.