3 ms·

The “force merge” process in an Elastic vector index took as long as 18 hours in one test. That’s a lot longer than a few hops across the network. This is not

• redwood 3y ago
  Got it (now you've got me going down the rabbit hole here reading things like https://stackoverflow.com/questions/60226215/why-segment-merge-in-elasticsearch-requires-stopping-the-writes-to-index https://stackoverflow.com/questions/60226215/why-segment-mer...). I think the key question is whether a healthy index in operation with a healthy amount of resources and configuration should ever require a force merge or if that's effectively an anti-pattern that suggests you're already up a cul-de-sac of risk and from there it sounds like if you have any segments larger than 5 GB in particular you may find yourself stuck unless you're an expert. I'd love to see someone who has some expert knowledge of elastic chime in to hear if the characterization here seems right? But admittedly not everyone's going to be a power user so if this isn't easy there's definitely a problem. It definitely makes sense that the faster the rate of change the more likely the engine has to combine results from multiple places until optimal placement on disc is found in steady state later, and hence query latency would rise.