chore: fix typos (#228)

Signed-off-by: Keming <kemingyang@tensorchord.ai>

Author: kemingy

.github/workflows/typos.yml

@@ -0,0 +1,22 @@
+name: Typos check
+
+on:
+  push:
+    branches: ["main"]
+  pull_request:
+    branches: ["main"]
+  merge_group:
+  workflow_dispatch:
+
+jobs:
+  run:
+    name: Spell Check with Typos
+    runs-on: ubuntu-latest
+    steps:
+    - name: Checkout Actions Repository
+      uses: actions/checkout@v4
+
+    - name: Check spelling of file.txt
+      uses: crate-ci/typos@master
+      with:
+        config: .typos.toml

.typos.toml

@@ -0,0 +1,2 @@
+[default.extend-words]
+ND = "ND"

bindings/python/src/pgvecto_rs/sdk/client.py

@@ -86,7 +86,7 @@ def search(
 
         Returns:
         -------
-            List of records and coresponding distances.
+            List of records and corresponding distances.
 
         """
         with Session(self._engine) as session:

bindings/python/tests/test_psycopg.py

@@ -45,7 +45,7 @@ def test_create_index(conn: Connection, index_name: str, index_setting: str):
     conn.commit()
 
 
-# The server cannot handle invalid vectors curently, see https://github.com/tensorchord/pgvecto.rs/issues/96
+# The server cannot handle invalid vectors currently, see https://github.com/tensorchord/pgvecto.rs/issues/96
 # def test_invalid_insert(conn: Connection):
 #     for i, e in enumerate(INVALID_VECTORS):
 #         try:

crates/service/src/worker/mod.rs

@@ -132,7 +132,7 @@ impl Worker {
         view.flush();
         Ok(())
     }
-    pub fn call_destory(&self, handle: Handle) {
+    pub fn call_destroy(&self, handle: Handle) {
         let mut protect = self.protect.lock();
         if protect.indexes.remove(&handle).is_some() {
             protect.maintain(&self.view);

docs/get-started.md

@@ -60,7 +60,7 @@ SELECT * FROM items ORDER BY embedding <-> '[3,2,1]' LIMIT 5;
 
 ## Half-precision floating-point
 
-`vecf16` type is the same with `vector` in anything but the scalar type. It stores 16-bit floating point numbers. If you want to reduce the memory usage to get better performace, you can try to replace `vector` type with `vecf16` type.
+`vecf16` type is the same with `vector` in anything but the scalar type. It stores 16-bit floating point numbers. If you want to reduce the memory usage to get better performance, you can try to replace `vector` type with `vecf16` type.
 
 ## Things You Need to Know
 

docs/installation.md

@@ -15,7 +15,7 @@ DROP EXTENSION IF EXISTS vectors;
 CREATE EXTENSION vectors;
 ```
 
-To acheive full performance, please mount the volume to pg data directory by adding the option like `-v $PWD/pgdata:/var/lib/postgresql/data`
+To achieve full performance, please mount the volume to pg data directory by adding the option like `-v $PWD/pgdata:/var/lib/postgresql/data`
 
 You can configure PostgreSQL by the reference of the parent image in https://hub.docker.com/_/postgres/.
 

docs/searching.md

@@ -12,13 +12,13 @@ If `vectors.k` is set to `64`, but your SQL returned less than `64` rows, for ex
 
 * Less than `64` rows should be returned. It's expected.
 * The vector index returned `64` rows, but `32` of which are deleted before but the index do not know since PostgreSQL vacuum is lazy.
-* The vector index returned `64` rows, but `32` of which are invisble to the transaction so PostgreSQL decided to hide these rows for you.
-* The vector index returned `64` rows, but `32` of which are satifying the condition `id % 2 = 0` in `WHERE` clause.
+* The vector index returned `64` rows, but `32` of which are invisible to the transaction so PostgreSQL decided to hide these rows for you.
+* The vector index returned `64` rows, but `32` of which are satisfying the condition `id % 2 = 0` in `WHERE` clause.
 
 There are four ways to solve the problem:
 
 * Set `vectors.k` larger. If you estimate that 20% of rows will satisfy the condition in `WHERE`, just set `vectors.k` to be 5 times than before.
-* Set `vectors.enable_vector_index` to `off`. If you estimate that 0.0001% of rows will satisfy the condition in `WHERE`, just do not use vector index. No alogrithms will be faster than brute force by PostgreSQL.
+* Set `vectors.enable_vector_index` to `off`. If you estimate that 0.0001% of rows will satisfy the condition in `WHERE`, just do not use vector index. No algorithms will be faster than brute force by PostgreSQL.
 * Set `vectors.enable_prefilter` to `on`. If you cannot estimate how many rows will satisfy the condition in `WHERE`, leave the job for the index. The index will check if the returned row can be accepted by PostgreSQL. However, it will make queries slower so the default value for this option is `off`.
 * Set `vectors.enable_vbase` to `on`. It will use vbase optimization, so that the index will pull rows as many as you need. It only works for HNSW algorithm.
 

src/bgworker/normal.rs

@@ -98,8 +98,8 @@ fn session(worker: Arc<Worker>, mut handler: RpcHandler) -> Result<(), IpcError>
                 Ok(()) => handler = x.leave()?,
                 Err(e) => x.reset(e)?,
             },
-            RpcHandle::Destory { handle, x } => {
-                worker.call_destory(handle);
+            RpcHandle::Destroy { handle, x } => {
+                worker.call_destroy(handle);
                 handler = x.leave()?;
             }
             RpcHandle::Stat { handle, x } => match worker.call_stat(handle) {

src/bgworker/upgrade.rs

@@ -60,7 +60,7 @@ fn session(handler: RpcHandler) -> Result<(), IpcError> {
         RpcHandle::Insert { x, .. } => x.reset(FriendlyError::Upgrade)?,
         RpcHandle::Delete { x, .. } => x.reset(FriendlyError::Upgrade)?,
         RpcHandle::Flush { x, .. } => x.reset(FriendlyError::Upgrade)?,
-        RpcHandle::Destory { x, .. } => x.reset(FriendlyError::Upgrade)?,
+        RpcHandle::Destroy { x, .. } => x.reset(FriendlyError::Upgrade)?,
         RpcHandle::Stat { x, .. } => x.reset(FriendlyError::Upgrade)?,
         RpcHandle::Vbase { x, .. } => x.reset(FriendlyError::Upgrade)?,
     }