Adrien Grand

This is an interesting idea! You do not mention it explicitly in the issue description, but presumably this only makes sense if an index sort is configured, otherwise merges may...

Thanks for explaining. The concern I have given how we're planning on never flushing/merging segments from the same group is that this would essentially perform the same as maintaining one...

I agree that better organizing data across segments yields significant benefits, I'm only advocating for doing this by maintaining a separate `IndexWriter` for each group instead of doing it inside...

> However, implementing this approach would lead to significant overhead on the client side (such as OpenSearch) both in the terms of code changes and operational overhead like metadata management....

> do we have such a class already (that would distinguish the tenants via filename prefix or so)? That's a nice idea all by itself (separate from this use case)...

> The resistance to it then and still now surprises me because (at least in my mind) there's a simple selector mechanism. I agree with the value of routing to...

This was the reasoning behind the introduction of `ReadAdvice.RANDOM`. By telling the operating system that the file has a random access pattern, it should be able to optimize for this...

Maybe we should take advantage of this change to simplify this postings format, by no longer making the hash function configurable, removing the abstraction for hash functions, and cutting over...

> Do you mean to change StringHelper class to add support for 128 bit hash because currently it creates 32-bit hash with Murmur 3? Sorry, I had overlooked that StringHelper...

Yes, let's add this in 10.1.