docs: update the num_partitions recommendation (#2401)

This commit is contained in:
BubbleCal
2025-05-23 23:45:37 +08:00
committed by GitHub
parent c4fbb65b8e
commit 1902d65aad
2 changed files with 5 additions and 5 deletions

8
Cargo.lock generated
View File

@@ -4150,7 +4150,7 @@ dependencies = [
[[package]]
name = "lancedb"
version = "0.19.1-beta.5"
version = "0.19.1"
dependencies = [
"arrow",
"arrow-array",
@@ -4237,7 +4237,7 @@ dependencies = [
[[package]]
name = "lancedb-node"
version = "0.19.1-beta.5"
version = "0.19.1"
dependencies = [
"arrow-array",
"arrow-ipc",
@@ -4262,7 +4262,7 @@ dependencies = [
[[package]]
name = "lancedb-nodejs"
version = "0.19.1-beta.5"
version = "0.19.1"
dependencies = [
"arrow-array",
"arrow-ipc",
@@ -4281,7 +4281,7 @@ dependencies = [
[[package]]
name = "lancedb-python"
version = "0.22.1-beta.5"
version = "0.22.1"
dependencies = [
"arrow",
"env_logger",

View File

@@ -291,7 +291,7 @@ Product quantization can lead to approximately `16 * sizeof(float32) / 1 = 64` t
`num_partitions` is used to decide how many partitions the first level `IVF` index uses.
Higher number of partitions could lead to more efficient I/O during queries and better accuracy, but it takes much more time to train.
On `SIFT-1M` dataset, our benchmark shows that keeping each partition 1K-4K rows lead to a good latency / recall.
On `SIFT-1M` dataset, our benchmark shows that keeping each partition 4K-8K rows lead to a good latency / recall.
`num_sub_vectors` specifies how many Product Quantization (PQ) short codes to generate on each vector. The number should be a factor of the vector dimension. Because
PQ is a lossy compression of the original vector, a higher `num_sub_vectors` usually results in