Hi Marcus, I am afraid at this stage Robert's opinion counts just as any other opinion, a single vote for option 1. We are collecting a community's feedback here, we are not changing any code nor voting for a yes/no. Once the voting is finished, we'll operate an action depending on the community's choice. If the action involves making a change and someone(Robert or whoever) feels to veto it, he/she will need to motivate the veto with technical merit.
In response to Uwe point: > >> On Tue, May 16, 2023 at 9:57 AM Uwe Schindler <u...@thetaphi.de> wrote: >> >>> I agree with Dawid, >>> >>> I am +1 for those two options in combination: >>> >>> - option 3 (make limit an HNSW specific thing). New formats may use >>> other limits (lower or higher). >>> - option 4 (make a system property with HNSW prefix). Adding the >>> system property must be done in same way like new properties for MMAP >>> directory (including access controller) so it can be denied by system >>> admin >>> to be set in code (see >>> >>> https://github.com/apache/lucene/blob/f53eb28af053d7612f7e4d1b2de05d33dc410645/lucene/core/src/java/org/apache/lucene/store/MMapDirectory.java#L327-L346 >>> for example). Care has to be taken that the static initializers won't >>> fail >>> is system properties cannot be read/set (system adminitrator enforces >>> default -> see mmap code). It also has to be made sure that an index >>> written with raised limit can still be read without the limit, so the >>> limit >>> should not be glued into the file format. Otherwise I disagree with >>> option >>> 4. >>> >>> In short: I am fine with making it configurable only for HNSW if the >>> limit is not glued into index format. The default should only be there to >>> by default prevent people from doing wrong things, but changing default >>> should not break reading/modifiying those indexes. >>> >>> Uwe >>> >>> Thanks Uwe, that's very useful! Just to fully understand it, right now the limit is not written in any file format, so you just want this behavior to be maintained right?
