kevindrosendahl commented on issue #12615: URL: https://github.com/apache/lucene/issues/12615#issuecomment-1806614314
@**[benwtrent](https://github.com/benwtrent)**: > if I am reading the code correctly, it does the following: > - Write int8 quantized vectors along side the vector ordinals in the graph (`.vex` or whatever has a copy of each vector). > - Continue to write vectors in `.vec`. I am guessing this is a stop-gap and you are thinking of removing this? Maybe not? The implementation will write the vectors at their requested encoding/quantization level into the graph. So if your vectors are `float[]`s with no quantization, `float[]`s go into the graph. If your vectors are `byte[]`s or `float[]`s with quantization, `byte[]`s go into the graph. If you do enable quantization, it keeps the full fidelity vectors around on the side for good measure, otherwise it only keeps a copy in the graph. > I have a concern around index sorting. How does building the graph & subsequent `getFloatVectors()` play with index sorting? Usually when folks sort an index, they expect to be able to iterate values in that given order. Is it horrifically slow to iterate `.vex` in this scenario? > > What do we think about always keeping `.vec` around? Probably should for re-ranking purposes once more extreme quantization measures are used. Interesting re: sorting. I hadn't given that much deep thought yet. To level-set a little on how I'm planning on approaching this, I think it's still a bit of an open question what performance is theoretically possible, and what type of index could possibly get us there. I'm trying first to get a sense of the possibilities there, so my main focus first is on measuring the single segment performance in order to rule out ideas not worth pursuing before investing too much time in them. If a single segment index works well, I think the next step would probably be to make sure it would work well with concurrent query execution over multiple segments, and then to start thinking about how it could be productionalized (sorted indexes, merges, etc). Thoughts on this approach? > One more question, have you tested your implementation in the situation where `.vex` cannot all be paged into memory and it faired ok? I've just got some first results for larger than memory performance, will post a separate comment. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
