pub struct IndexInfo {
pub name: Vec<u8>,
pub folded: Vec<u8>,
pub root: u32,
pub unique: bool,
pub columns: Vec<IndexColumnInfo>,
pub partial_sql: Option<Vec<u8>>,
pub origin: IndexOrigin,
pub conflict: Option<ConflictAction>,
pub prefix_rows: Vec<i64>,
pub analysed_rows: Option<i64>,
pub metric: Option<IndexMetric>,
}Expand description
An index over a table.
Fields§
§name: Vec<u8>The index name.
folded: Vec<u8>The ASCII-folded lookup key.
root: u32The root page of the index B-tree.
unique: boolWhether the index enforces uniqueness.
columns: Vec<IndexColumnInfo>The key columns, in order.
partial_sql: Option<Vec<u8>>The partial-index predicate, as written.
origin: IndexOriginWhere the index came from.
conflict: Option<ConflictAction>The ON CONFLICT clause the constraint that created it carried.
prefix_rows: Vec<i64>For each leading prefix of the key, the average number of rows sharing
it, as ANALYZE measured.
Empty until the schema has been analysed, which is the usual state and not an error: the planner falls back to SQLite’s own guesses, and those guesses are what make an unanalysed plan match the reference’s.
analysed_rows: Option<i64>How many entries the index itself holds, as ANALYZE measured.
The same number as the table’s row count for an ordinary index, and a different one for a partial index, which holds only the rows its predicate accepted. It is what lets the planner price reading the whole of such an index against scanning the table it is on - 120 entries against 6,000 rows, in the case this was found on.
None until the schema has been analysed.
metric: Option<IndexMetric>The distance a vector index minimises, when it is one the planner may
trust to answer for it. See IndexMetric.