logoalt Hacker News

devy • today at 1:52 PM • 3 replies • view on HN

A couple preliminary findings if you are considering adopting this extension to replace your previous pgvector's HNSW indexing.

- pg_vectorsearch uses a quantized IVF index called PRISM. PRISM caps at 1968 dimensions for vectors. If your previous HNSW index has more dimensions than that, you're SOL (at least for now until they fix that).

- pg_vectorsearch requires Postgres version 18 or above. If you run PG versions below that you need to migrate your database first. Many legacy PG production environment are way dated on PG 14 or 15, migration is prohibitively high cost to just try this out.

- pg_vectorsearch shipped yesterday and it's obviously alpha. Hasn't been battle tested in production environments outside of Timescale's. Also since it's so new, it isn't on Azure's allowed-extension list or any other Hyperscale's managed PG instances' allowed extension list. It takes time to graduate from alpha and mature. So if you run managaed PG instances from hyperscaler's cloud, you're SOL (at least for now until this matures into those ecosystems) or you have to migrate to a PG 18 self-hosted.

Replies

Arch485 • today at 3:46 PM

Re: Max dimensions: You can truncate your input vector specifically for the index, and then when querying, you can query the index via a truncated vector and perform an additional full-length comparison as well.

For example: (taken from a project I'm currently working on)

```

SELECT *

FROM report_embeddings a

INNER JOIN report_embeddings b

    ON (

        subvector(a.embedding, 1, 768)::vector(768) <->
subvector(b.embedding, 1, 768)::vector(768)

    ) < $1

    AND b.id != a.id
WHERE a.id = $2

    AND a.embedding <-> b.embedding < $1
```

In this example, I truncate the embedding to 768 dimensions for the index and the lookup, (see the INNER JOIN) but do an additional full vector comparison as well. (in the WHERE clause)

This performs a fast but less accurate lookup into the index, and then only does the non-indexed full vector check for the matched results.

➕ show 1 reply
curious_cat_163 • today at 2:02 PM

I have used pgvector on an Azure DB. It did a "reasonable" job. I am not an expert on HNSW vs PRISM but because it is all backward compatible, I am curious why they didn't just send a PR to the pgvector folks?

Like, I would love to learn more about the design process that led to a whole new thing. I am sure the decision was not taken lightly, but the README is very thin on the details for why anyone should go through the troubles above, at least in the making of it.

➕ show 4 replies
ltononro • today at 2:48 PM

so basically you should use Qdrant anyway lmao :p