Both what Allesandro said and what Bruno said: make it configurable and
move it. Both are good and not mutually exclusive and could happen in any
order.
Marcus, are you against configurability? In particular, I propose a
simple Integer.getInteger("lucene.hnsw.maxDimensions", 1024). Your
That's actually a good idea.
+1
Am 10.05.2023 um 09:22 schrieb Bruno Roustant:
*Proposed option:* Move the max dimension limit lower level to a HNSW
specific implementation. Once there, this limit would not bind any
other potential vector engine alternative/evolution.
*Motivation:* There
*Proposed option:* Move the max dimension limit lower level to a HNSW
specific implementation. Once there, this limit would not bind any other
potential vector engine alternative/evolution.
*Motivation:* There seem to be contradictory performance interpretations
about the current HNSW
Over the past month, and lots of working with Lucene, I've moved to Robert
Muir's camp.
*Proposed option*: We focus our efforts on improving the testing
infrastructure, stability, and performance of the feature as is prior to
introducing more complexity. Someone could benefit the community to
+1
Michael Wechner
Am 09.05.23 um 14:08 schrieb Alessandro Benedetti:
*Proposed option*: make the limit configurable
*Motivation*:
The system administrator can enforce a limit its users need to respect
that it's in line with whatever the admin decided to be acceptable for
them.
The default
*Proposed option*: make the limit configurable
*Motivation*:
The system administrator can enforce a limit its users need to respect that
it's in line with whatever the admin decided to be acceptable for them.
The default can stay the current one.
This should open the doors for Apache Solr,
We had a very long-running (and heated) thread about this (*[Proposal]
Remove max number of dimensions for KNN vectors*).
Without repeating any of it, I recommend we move this forward in this way:
*We stop any discussion* and everyone interested proposes an option with a
motivation, then we
