Set ivfflat.probes

[edgarbrignoni]

Is there's a way ivfflat.probes can be set permanently?

Kind Regards,

Edgar B.

[jkatz]

You can set the value permanently in the postgresql.conf file or via ALTER SYSTEM.

[ankane]

Hi @edgarbrignoni, you can also set it on the database or user:

ALTER DATABASE mydb SET ivfflat.probes = 10;

or

ALTER USER myuser SET ivfflat.probes = 10;

(then reconnect for it to take effect)

[edgarbrignoni]

Thank you for the feedback! I will try those settings.

[ankitml]

Hey Folks, Setting this param works. However checking its value has been elusive.
Neither of these two approaches show this setting on the database.

• SHOW ivfflat.probes
• SELECT name, setting
  FROM pg_settings where name LIKE '%prob%';

[ankane]

It shows up with SHOW ivfflat.probes; when set on the database (be sure to reconnect after changing as mentioned above). Also, it's a regular Postgres config variable, so any behavior isn't specific to pgvector.

[ankitml]

Thanks, I was missing the reconnect :)

[xak2000]

I encountered similar problem:

SHOW hnsw.ef_search;

Resulted in:

SQL Error [42704]: ERROR: unrecognized configuration parameter "hnsw.ef_search"

And

SELECT * FROM pg_settings WHERE name LIKE '%hnsw%';

Resulted in empty result.

I experimented a little and both queries are starting to work after I do in the current session any action, that initializes pgvector extension. E.g. It could be CREATE TABLE with a vector column. Or a SELECT from such table using any distance-calculating function in the query (e.g. SELECT *, embedding <=> '[1]' AS distance FROM vector_store;).

If I re-connect to the DB after this, the SHOW hnsw.ef_search; command starts to return an "unrecognized configuration parameter" error again.

So, it looks like the pgvector extension does not initialize automatically until something that "touches" it happens.
That is the reason why sometimes SHOW and SELECT .. FROM pg_settings works, while sometimes it does not work.

@ankane

Also, it's a regular Postgres config variable, so any behavior isn't specific to pgvector.

So, I would say, while it is a regular config variable, the behavior is still not exactly standard/expected. With all regular Postgres config variables you can always run SHOW to get the current value of this variable, while with pgvector variables the ability to successfully do this depends on sneaky conditions.