Can we switch to the regular postings list writer/reader for IVF?

[benwtrent]

Description

Right now for IVF, we have copy-pasted the DocIdsWriter and modified it.

But, I think our postings list should likely be in doc-id order. Consequently, let's see how much we can gain by possibly switching to just using Lucene's postings writer/reader. Maybe there is some sweet performance improvements we are leaving behind by using the bkd DocIdsWriter.

//cc @jimczi

[elasticsearchmachine]

Pinging @elastic/es-search-relevance (Team:Search Relevance)

[iverase]

The idea for not sorting the posting list by doc id is to avoid mixing vectors belonging to the cluster with soar vectors. This in theory should benefit bulk scoring.

[benwtrent]

The idea for not sorting the posting list by doc id is to avoid mixing vectors belonging to the cluster with soar vectors. This in theory should benefit bulk scoring.

@iverase I can understand that. The downside is that we aren't sorting at all right now. Running benchmarks indicate no significant downsides from what I can tell.

#129655

[iverase]

IIRC it was noticable when making n_probe large. Maybe that's not the use case we should aim to optimize.

[benwtrent]

@iverase I wonder if there is a middle ground. Meaning we sort by doc ID for the initial assignments and sort by doc ID for the spill over assignments? Effectively having two blocks of doc ids.

[iverase]

I think at some point we might want to have that distinction so it sounds good to me.