Andrew Kane
Andrew Kane
Looks like that still didn't fix it, so reverted.
Found and fixed the issue in fa52511eaa90f1b1f3156e00bcc7cde4c56cbae2, so going to restore.
Hi @hbhanawat, thanks for the PR, but 2 is about being called for the index scan rather than the index build.
Hi @MMeent, thanks for the explanation. It sounds like this would need to be addressed in the executor (updated the list to reflect this). fwiw, pgvector doesn't currently set `scandesc->xs_orderbyvals`...
Amazing, huge thanks @hlinnaka!
Closing this out, as most of the original items have been worked on.
Hi @alanwli, I'm not sure there's a way to address this that doesn't affect search speed, but it may be worth the tradeoff. I've pushed a solution to [kill-prior-tuple](https://github.com/pgvector/pgvector/compare/kill-prior-tuple) branch,...
Here's a rough summary of the situation: As elements get updated/deleted, either speed or recall has to give until the graph can be repaired (which currently happens on vacuum, as...
That notice is not related to this issue. Please see the [docs on index build time](https://github.com/pgvector/pgvector?tab=readme-ov-file#index-build-time) for how to resolve.
Hey @StanBright, thanks for reporting. Postgres use [intervalstyle](https://www.postgresql.org/docs/current/datatype-datetime.html#DATATYPE-INTERVAL-OUTPUT) to determine how intervals are displayed. It defaults to `postgres`, which is probably what you're seeing in the DB console. It looks...