mirror of
https://github.com/lancedb/lancedb.git
synced 2026-11-13 22:26:53 +00:00
Jack YeandClaude Sonnet 5
de95ed3f6d
A broad documentation pass across the areas LanceDB Enterprise and Embedded diverge on most: **Data Curation** -- GPU Function execution, Slurm scheduling (and what Slurm is, for readers new to it), blob late materialization as its own page, joins, aggregation/profiling, sampling, near-duplicate detection, chunking, distributed shuffle, and IVF-partition clustering. **Feature Engineering** -- computed columns and materialized views, restructured to lead with the Function-based path and show the SQL form side by side with Python throughout; a single Auto Refresh page instead of duplicating scheduling details on every refresh page; adaptive execution; checkpointing; GPU and Slurm placement for refresh workers; a Training Cache page for the PyTorch data loader's automatic cache benefit. **Security & Governance** -- an Audit Log reference (schema, access, grants), Secrets promoted to an ordinary catalog object with their own SQL DDL and a vending/rotation guide, and privilege-table fixes verified against the authorization source. **Deployment & Maintenance** -- Horizontal Scaling and OpenTelemetry moved into a real Deployment area; Automated Cleanup folded into Intelligent Auto-Maintenance (every other maintenance decision already lived there); RTE Compaction and Advanced Conflict Resolution documented in depth. **Landing page** -- the Enterprise feature comparison table reorganized (several redundant or stale rows removed, several new areas added), and the "why Enterprise" bullets replaced with ones tied to a concrete page (Performance, Scale, Fault tolerance, Multicloud deployment, Simplify operations) instead of vague promises. Plus a full pass addressing lancedb-gatekeeper's review: a real test-safety bug (a quickstart test could silently overwrite and delete a deployment's own `frames` table), a fabricated SQL statement with no backing implementation, an actual dedup-guarantee bug in `take_row_ids`, and dozens of documentation-accuracy fixes verified against source rather than taken on faith -- each either fixed, or left with an explicit note on why it needs a feature or deployment owner's sign-off instead of being guessed at. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_018PXMCbRH6i5w47TsjeEUMT --------- Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
59 lines
2.3 KiB
Plaintext
59 lines
2.3 KiB
Plaintext
---
|
|
title: "Vector distance functions"
|
|
sidebarTitle: "Vector Distance"
|
|
description: "cosine_distance, distance, exact_distance and inner_product: per-row vector distance, and the ORDER BY rewrite into vector search."
|
|
icon: ruler
|
|
keywords: ["distance", "cosine_distance", "exact_distance", "inner_product", "vector search", "sql", "scalar function"]
|
|
availability:
|
|
embedded: unavailable
|
|
enterprise: available
|
|
---
|
|
|
|
```text
|
|
cosine_distance distance exact_distance inner_product
|
|
```
|
|
|
|
<Warning>
|
|
Distance functions can evaluate arrays per row. Some deployment versions also
|
|
recognize `ORDER BY distance(vector, query_vector) LIMIT k` over a table scan
|
|
and plan it as vector search, with indexed or flat search as appropriate.
|
|
Where available, `exact_distance` evaluates distance without that rewrite.
|
|
Confirm the functions supported by your deployment and inspect SQL
|
|
[`EXPLAIN`](/sql/dql/explain); the function name alone does not guarantee an
|
|
index-backed plan. See [SQL vector search](/basics/sql#no-vector-sql).
|
|
</Warning>
|
|
|
|
A third, optional argument is a comma-separated options string, and only
|
|
`distance` and `exact_distance` accept one; `cosine_distance` and
|
|
`inner_product` are plain two-argument functions. `metric` selects `l2`
|
|
(default, alias `euclidean`), `cosine`, or `dot`. `nprobes` and `use_index`
|
|
only affect `distance`, since it's the only one of the two that the
|
|
index-search rewrite applies to in the first place -- `exact_distance` is
|
|
never rewritten into an index search, so passing it `use_index`/`nprobes`
|
|
does nothing; use a plain `distance` call with `use_index=false` to force a
|
|
flat scan instead:
|
|
|
|
<CodeGroup>
|
|
```sql SQL icon="database"
|
|
SELECT id FROM documents
|
|
ORDER BY distance(embedding, ARRAY[0.1, 0.2, 0.3], 'metric=cosine,nprobes=20')
|
|
LIMIT 10
|
|
|
|
-- Force a flat scan, bypassing the index:
|
|
SELECT id FROM documents
|
|
ORDER BY distance(embedding, ARRAY[0.1, 0.2, 0.3], 'use_index=false')
|
|
LIMIT 10
|
|
```
|
|
</CodeGroup>
|
|
|
|
## What to read next {#next}
|
|
|
|
<CardGroup cols={2}>
|
|
<Card title="SQL vector search" icon="magnifying-glass" href="/basics/sql#no-vector-sql">
|
|
Server-version requirements and the supported `ORDER BY` query forms.
|
|
</Card>
|
|
<Card title="EXPLAIN" icon="diagram-project" href="/sql/dql/explain">
|
|
Confirm whether a query planned as an index-backed vector search.
|
|
</Card>
|
|
</CardGroup>
|