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

Fix Docs : minor grammar fixes (#2218)

Browse Source 
* fix(docs): fix typos and some links in documentation

* fix(docs): correct typo in filtering.md

* Update qdrant-landing/content/documentation/headless/snippets/inference/jinaai-upsert/generated/typescript.md

Co-authored-by: Abdon Pijpelink <abdon.pijpelink@qdrant.com>

* Update qdrant-landing/content/documentation/headless/snippets/inference/multiple/generated/typescript.md

Co-authored-by: Abdon Pijpelink <abdon.pijpelink@qdrant.com>

* Update qdrant-landing/content/documentation/hybrid-cloud/configure-scale-upgrade.md

Co-authored-by: Abdon Pijpelink <abdon.pijpelink@qdrant.com>

* Update qdrant-landing/content/documentation/cloud-api.md

Co-authored-by: Abdon Pijpelink <abdon.pijpelink@qdrant.com>

---------

Co-authored-by: Abdon Pijpelink <abdon.pijpelink@qdrant.com>
This commit is contained in:
Mohamed Arbi
2026-03-26 17:23:36 +01:00
committed by GitHub
co-authored by Abdon Pijpelink
parent 3f3ef1ad20
commit c0db45ed8f
58 changed files with 75 additions and 75 deletions
Download Patch File Download Diff File Expand all files Collapse all files
qdrant-landing/content/articles/qdrant-1.3.x.md
+2 -2
View File
@@ -33,7 +33,7 @@ Your feedback is valuable to us, and are always tying to include some of your fe
## New features
### Asychronous I/O interface
### Asynchronous I/O interface
Going forward, we will support the `io_uring` asychnronous interface for storage devices on Linux-based systems. Since its introduction, `io_uring` has been proven to speed up slow-disk deployments as it decouples kernel work from the IO process.
@@ -201,7 +201,7 @@ Internally, `is_empty` was not using the index when it was called, so it had to
### Faster read access with mmap
If you used mmap, you most likely found that segments were always created with cold caches. The first request to the database needed to request the disk, which made startup slower despite plenty of RAM being available. We have implemeneted a way to ask the kernel to "heat up" the disk cache and make initialization much faster.
If you used mmap, you most likely found that segments were always created with cold caches. The first request to the database needed to request the disk, which made startup slower despite plenty of RAM being available. We have implemented a way to ask the kernel to "heat up" the disk cache and make initialization much faster.
The function is expected to be used on startup and after segment optimization and reloading of newly indexed segment. So far this is only implemented for "immutable" memmaps.