mirror of
https://github.com/lancedb/lancedb.git
synced 2026-10-14 07:42:28 +00:00
Jack Ye
19f8f396ec
Ten merges and renames, all in one direction: fewer pages, each covering a whole subject. Table absorbs schema evolution and versioning. Vector search absorbs multi-vector. Explain absorbs explain analyze. Reranking was seven pages -- an overview and six rerankers of a few dozen lines each -- and is now one. The vector index page absorbs quantization, which was only ever a parameter of it. Indexing moves to Manage, where the other catalog objects are. The operational half stays in Operate as one Indexing page, absorbing GPU indexing -- which was filed in sophon despite importing lancedb's snippets and being mostly open-source content with one Enterprise-badged section. Performance was a single page aggregating tips for four unrelated operations, which is hard to keep current. Each section now sits with the operation it is about: ingestion tips on Insert, index tips on Indexing, compaction tips on Compaction, query tips on Search. Data Types leaves Concepts. The type reference belongs in the SQL reference, which already described the same types from the query side; Table now carries a short summary that points there. The multimodal material it had absorbed is its own page again, since storing blobs is a task rather than a type definition. Query becomes Semantic Search, Branches becomes Branch, and the Enterprise Security page becomes Compliance. Redirects cover every moved URL, and 30 files were repointed at the merged anchors.
52 lines
1.6 KiB
Plaintext
52 lines
1.6 KiB
Plaintext
---
|
|
title: "EXPLAIN"
|
|
sidebarTitle: "Explain"
|
|
description: "Reading the plan for a statement, and measuring it."
|
|
icon: map
|
|
keywords: ["explain", "explain analyze", "query plan", "describe"]
|
|
---
|
|
|
|
<Badge color="red">Enterprise</Badge> [SQL runs on a deployment.](/sql)
|
|
|
|
```sql
|
|
EXPLAIN SELECT * FROM documents WHERE identifier < 1000
|
|
EXPLAIN ANALYZE SELECT * FROM documents WHERE identifier < 1000
|
|
```
|
|
|
|
`EXPLAIN` resolves the plan without running the query. `EXPLAIN ANALYZE`
|
|
executes it and annotates every operator with runtime metrics — elapsed time,
|
|
rows produced, bytes read, index comparisons.
|
|
|
|
The operators are the same ones the SDK methods produce, so the reasoning about
|
|
index coverage and filter pushdown carries across unchanged. The two pages that
|
|
explain how to read them:
|
|
|
|
<CardGroup cols={2}>
|
|
<Card title="Explain" icon="map" href="/search/explain">
|
|
Reading a plan: operators, pushdown, index usage.
|
|
</Card>
|
|
<Card title="Explain Analyze" icon="gauge" href="/search/explain">
|
|
Reading the metrics, and a worked before/after.
|
|
</Card>
|
|
</CardGroup>
|
|
|
|
## What to look for {#what-to-look-for}
|
|
|
|
| Sign | Means |
|
|
| --- | --- |
|
|
| `ScalarIndexQuery` | the predicate used a scalar index |
|
|
| `LanceScan` with high `bytes_read` | no index, or too many columns selected |
|
|
| `FilterExec` above a search | the filter ran after search rather than pushing into it |
|
|
| `ANNSubIndex` / `ANNIvfPartition` | the vector index was used |
|
|
|
|
A `LanceScan` feeding a join is the common one worth acting on — see
|
|
[Joins](/sql/join#performance).
|
|
|
|
## DESCRIBE {#describe}
|
|
|
|
```sql
|
|
DESCRIBE documents
|
|
```
|
|
|
|
The table's columns and types, without a plan.
|