krzysztof/landing_page
1
0
Fork 0
mirror of https://github.com/qdrant/landing_page.git synced 2026-10-05 10:58:32 +02:00
Code Issues Packages Projects Releases Wiki Activity

Adjust section explaining deferred points for Qdrant 1.17.1 (#2235)

Browse Source
This commit is contained in:
Tim Visée
2026-03-27 17:28:40 +01:00
committed by GitHub
parent 063b0c7111
commit 59d90d9978
1 changed files with 4 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
qdrant-landing/content/documentation/search/low-latency-search.md
+4 -2
View File
@@ -49,6 +49,8 @@ Search latency can vary depending on where the data is in this process. Querying
If your application requires a consistently low search latency, set the [search parameter](/documentation/concepts/search/#search-api) `indexed_only` to `true`. With this setting enabled, search operations will only consider indexed data, ensuring more consistent and lower response times. The tradeoff is that the most recent data might not be included in search results until it has been indexed.
Enabling `indexed_only` can cause recently updated data to temporarily disappear from search results until it is indexed again. To mitigate this, set the `prevent_unoptimized` optimizer setting to `true` when [creating or updating a collection](/documentation/concepts/collections/#update-collection-parameters), or globally in the [configuration file](/documentation/concepts/optimizer/). This prevents the creation of large unoptimized segments by throttling updates from the update queue to match the indexing rate.
Enabling `indexed_only` can cause recently updated data to temporarily disappear from search results until it is indexed again. To mitigate this, set the `prevent_unoptimized` optimizer setting to `true` when [creating or updating a collection](/documentation/concepts/collections/#update-collection-parameters), or globally in the [configuration file](/documentation/concepts/optimizer/). It prevents creating segments with a large amount of unindexed data for searches. Instead, once a segment reaches the so called `indexing_threshold`, all additional points will be added in 'deferred state'. Deferred points are not yet visible in reads but are still handled in writes. Deferred points will be promoted to visible points once the segment is optimized.
<aside role="alert"><code>prevent_unoptimized</code> is an experimental feature; its behavior may change in future releases and it is not recommended for production use yet.</aside>
In practice this behavior is good for three things. It prevents high search latencies because the search space on unoptimized data remains small. It prevents throttling update processing on large update queues. And it prevents creating a lot of small segments which would be expensive to optimize. A trade-off is eventual consistency, meaning updates might not be immediately visible. It can be mitigated by opting out on a per-update basis by setting `wait=true`. Or you might completely disable the feature by setting `indexed_only=false` and `prevent_unoptimized=false`.
<aside role="alert"><code>prevent_unoptimized</code> is an experimental feature; its behavior may change slightly in future releases and it must be used with care.</aside>