You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Provide written answers to the technical questions on PipNN #1021
Whether the prune rule can be more general, whether we can adopt it, whether it requires so much memory.
Is PipNN disk friendly, is it update friendly?
Do we really need two sets of algorithms? For example, if PipNN and or some of its subroutines are strictly superior, can we just start swapping out instead of introducing another set of methods?
technically hashprune could be used as a itermidiate prunning in vamana as well. all candates in insertion flows to hashprune instead of trigger robust prune. Need to verify
From experiment, Pipnn is disk friendly, on NVMe QPS is Vamana same level. For update, the algo is not support incremental build unless we record the paritiion information which is not worthy it. We can relay on Vamana to do incremental build and when the quality dropped to a bar, trigger pipnn rebuild
For current milestone and test, seprate algo is more favourable, we can discuss if build phase could be replaced by Pipnn entirely after we collect more data after checkin
Activity
SeliMeli commentedon May 7, 2026