4 ms·
> it is an inherent design issue it would definitely be a design issue if the extension could only support a single index type, but Andrew already has plans to
by kiwicopple 3y ago
> it is an inherent design issue
it would definitely be a design issue if the extension could only support a single index type, but Andrew already has plans to implement HNSW in 0.5.0:
https://github.com/pgvector/pgvector/issues/27 https://github.com/pgvector/pgvector/issues/27
- KRAKRISMOTT 3y ago> Andrew already has plans to implement HNSW in 0.5.0: 0.5.0 according to the GitHub issue tracker has been more than a year in the making and it is not any closer to release.
- mattashii 3y agoCould you please not pull things out of context? If you say "no, pgvector is not slow, it is the index that is slow", while pgvector has been designed with only a single index type, then it is a design issue of pgvector in that the wrong type of index was chosen as the included index type. That there are plans to solve this issue doesn't mean it is not an issue; indeed it validates my point that pgvector currently has design flaws. Telling (potential) users to wait for 6 months for performance doesn't mean much if there are more performant alternatives readily available right now; a starving person isn't helped by a meal made available half a world away.
- Dhruva23 3y agoDidn't you (Neon) just announce pg_embedding and claim 20x performance over pg_vector even though pg_embedding just runs in memory and doesn't replicate the data? Scary that database engineers do not understand how reckless that is.