Leonid Boytsov

Well, currently the method doesn't guarantee returning at least K results. However, for large enough data set it should be at least K. How many data points do you have?

@shubaoliu I am saying that there's no guarantee yet. However, if getting < K NNs happens on a large data set, we need to investigate.

@shubaoliu thank you for details. efConstruction shouldn't really affect this. Increase in efSearch can help, but I don't understand why there's any diff on a relatively large data set.

@yurymalkov yes, it's still not very likely for large data sets. Anyways, we should, perhaps, forbid setting efSearch < K. In fact, kgraph does so.

@yurymalkov can't do it for efConstruction, because K isn't known in advance. Perhaps, the easiest solution is to 1) Fill the result queue with K first data points 2) Use...

Hi @saj1919 I haven't looked into this yet, perhaps, it's time to do. Can you tell me a bit more about your data and indexing process: 1) data dimensionality? 2)...

@phdowling there's no guarantee. But setting ``efSearch`` to a higher value usually helps. Increasing M and ``efConstruction`` also helps. Setting ``post`` to 1 or 2 also helps. However, all these...

@alberto-oliveira 1) could you share the data 2) what's your target retrieval speed? that's how fast should it be?

@Dronablo ok, I will check this out. Of course, it's a bug, but as a workaround it's easy to track which indices are empty or not using additional data that...

Hi @howardwang15 sorry about the inconvenience. There's a somewhat inefficient but legit workaround now. When you save the index specify save_data=True. When you load the index, specify load_data=True.