Hacking pgvector for performance
summary
Modified pgvector keeps the vector index in persistent external memory via a background worker and replaces Postgres page/tuple handling with plain arrays, removing buffer and tuple-sort overhead and giving ~2–2.5× speedup. Pushing the distance filter into the index scan (push filters into index scan) cuts a 500 ms filtered query to ~20 ms; moving distance compute to GPU (GPU offload) drops that to ~2–3 ms (up to ~200× vs baseline). Proof‑of‑concept code is on GitHub.
AI-written summary · about
chapters (7)
- 0:00Introduction and background
- 7:32Motivation for vector search
- 19:14Postgres and pgvector basics
- 24:52Hacking pgvector for performance
- 33:42Pushing down filters and limits
- 38:12General remarks and future work
- 43:07Q&A
related talks
52mVector search is now boring, but PostgreSQL has ways to go
41mPostgreSQL for AI. Real Vector Search in PostgreSQL
04mSupercharging GenAI PostgreSQL Vector Search Optimization
53mVectors: how to better support a nasty data type in PostgreSQL
52mpgvector Newbie to Expert
25mVector data in Postgres - how's it different from "normal" data?
48mFrom Text to Meaning: pgvector Transforms PostgreSQL Search
32mHacking Postgres Executor For Performance