Vector search on PostgreSQL gets slower as data grows, and memory is short. What do you review?
Why D is the answer
Compute, memory and storage for the vector workload
Vector workloads depend on compute, memory and storage, so review those resources when search slows and memory runs short.
In detail
- Vector indexes use a lot of memory.
- Review compute, memory and storage for the workload.
- Vector indexes need memory.
Use case
An illustrative scenario, not a real incident.
Vector queries slow down as data grows, and the server is short of memory. Reviewing compute and memory for the workload finds the limit.
See it in different ways
stateDiagram-v2 [*] --> SequentialScan: no vector index SequentialScan --> AddIndex: slow on large tables AddIndex --> ApproximateSearch: HNSW ApproximateSearch --> ReviewResources: memory is short ReviewResources --> ApproximateSearch
flowchart TD
Q{"What is exhausted?"}
Q -->|"Memory"| A0["Scale memory"]
Q -->|"CPU"| A1["Scale compute"]
Q -->|"Storage"| A2["Scale storage"]Key point: Vector workloads need memory.
Why the other options are wrong
- A. The table's primary key type
- Key type does not fix a memory shortage.
- B. The row-level security policies
- Security policies are not the cause.
- C. The client driver version of your query tool
- The client driver does not affect server memory.