The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
When a pgvector query uses an approximate nearest-neighbor (ANN) index, permission filters can leave a restricted user with fewer than the requested number of results. The index scans a limited set of candidates, then SQL filters discard rows the user cannot access. PostgreSQL row-level security (RLS) can still enforce access correctly; it does not make an approximate search examine more candidates or guarantee a full top-k result set.
Why can a restricted user get fewer results?
pgvector uses exact nearest-neighbor search by default. Adding an HNSW or IVFFlat index changes the search to an approximate one, trading some recall for speed. With an approximate index, pgvector applies ordinary SQL filters after the index scan. If many scanned candidates fail a permission predicate, they are removed before the query’s LIMIT is filled. pgvector documentation
For illustration, pgvector’s documentation says a filter matching 10% of rows with the default HNSW ef_search of 40 yields four matching rows on average. That is an explanatory example, not a production benchmark or a guarantee. Actual results depend on the query, data distribution, index settings, dead tuples, planner choices, and policy shape.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteThis is why “fewer answers” can resemble an authorization failure even when access control works as intended. The user’s eligible subset may be small relative to the shared index’s candidate pool. Result count, authorization correctness, semantic relevance, and latency are separate things to test.
#1 Best Overall
What RLS guarantees—and what it does not
PostgreSQL RLS limits which rows normal queries may return and which rows data-modification statements may insert, update, or delete. When RLS is enabled and no applicable policy allows access, PostgreSQL uses default deny. RLS is an authorization mechanism, not a nearest-neighbor recall setting. PostgreSQL 18: Row Security Policies
PostgreSQL generally enforces security-policy conditions before qualifications in user queries, subject to documented exceptions such as leakproof functions. That policy evaluation order does not change the approximate index’s candidate-search budget. PostgreSQL 18: CREATE POLICY
Rank #2
Check the role used by the application, not only a developer account. Superusers and roles with BYPASSRLS bypass row security. Table owners normally bypass it too, unless the table is configured with FORCE ROW LEVEL SECURITY. These exceptions can make a test run under an owner or privileged role behave differently from the production app role. PostgreSQL 18: Row Security Policies
How to verify whether filtering is the cause
- Create representative test data. Include broad-access and highly restricted users, with realistic tenant and document permissions.
- Run identical queries under the real application role. Keep the semantic query and requested
LIMITthe same while testing different permission selectivities. - Compare ANN results with an exact baseline. For each case, record the returned count, overlap or recall against exact results, latency, and query plan. pgvector documents disabling index scans locally within a transaction as one way to obtain exact results for comparison. pgvector documentation
- Test any proposed tuning or layout. Try iterative scans, partial indexes, or partitioning on the same fixture, and inspect the plan to confirm which strategy ran. A setting being present does not prove the query used it.
- Test authorization independently. Confirm no unauthorized row reaches the application response or prompt context. Include owner and bypass-role cases, and perform the primary checks as the production application role.
- Check the installed extension version. Iterative index scans require pgvector 0.8.0 or later; do not assume a setting or behavior exists on older versions. pgvector documentation
Which changes can improve result counts?
Choose a strategy based on filter selectivity, required recall, p95 latency, index size and maintenance cost, the number of tenant or filter values, and isolation needs. Measure on the workload you expect to run; the options have different trade-offs.
| Approach | When it fits | Trade-offs and limits |
|---|---|---|
| Exact search over the authorized subset | Small eligible subsets or cases where full recall matters. A conventional index on filter columns can help make exact nearest-neighbor search practical when the filter matches a low percentage of rows. | Exact search has perfect recall, but its speed depends on the amount of eligible data and the query plan. pgvector documentation |
| Iterative ANN scans | HNSW or IVFFlat searches where post-scan filtering leaves too few results. | Available starting in pgvector 0.8.0. Scanning continues until enough qualifying rows are found or a configured limit is reached: hnsw.max_scan_tuples or ivfflat.max_probes. It adds work and does not guarantee a filled result set. Strict ordering keeps returned rows in exact distance order; relaxed ordering can improve recall while returning rows slightly out of order. pgvector documentation |
| Partial indexes | A small number of fixed filter values. | Less suitable when there are many distinct values, because each partial index represents a specific subset. pgvector documentation |
| Partitioning or separate tables | Many filter values or a need to isolate tenant search spaces. | Requires a suitable data layout and operational management. pgvector notes that vectors from other tenants in a shared approximate index can affect both recall and speed. pgvector documentation |
HNSW or IVFFlat: does the index choice solve it?
Neither index type removes the underlying issue that approximate search examines candidates and filters may discard them. The pgvector project characterizes HNSW as generally offering a better speed-recall trade-off, with slower builds and higher memory use. IVFFlat builds faster and uses less memory, but has lower query performance in that trade-off. These are qualitative project-level comparisons, not predictions for a particular workload. pgvector documentation
Compare both against exact search using the same permissions and queries. If the eligible set is small, exact search may be the simpler and more dependable option. If ANN is needed, tune scan behavior and consider an index or data layout that reduces competition from rows outside the user’s access scope.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
