mirror of
https://github.com/lancedb/lancedb.git
synced 2026-10-14 07:42:28 +00:00
Brendan Clement
bbadf0dbea
The SDK now sends CREATE MATERIALIZED VIEW and REFRESH MATERIALIZED VIEW to a db:// deployment as SQL, and refuses source_version on a remote refresh. Current Sophon source accepts both statements, with CASCADE and WITH (full = true), but only on deployments that enable materialized views, and whether a refresh rebuilds the view or reconciles changes depends on configuration. The pages said there is no CREATE MATERIALIZED VIEW statement, that refreshes are incremental by default and that CASCADE is not implemented. The refresh, management and SQL reference pages now describe what the SDK sends, say that materialized views are experimental and must be enabled on a deployment, and leave refresh behaviour, CASCADE and the job type to the deployment's version and configuration. The SQL and management summaries list CREATE MATERIALIZED VIEW. No deployment was exercised.
73 lines
2.2 KiB
Plaintext
73 lines
2.2 KiB
Plaintext
---
|
|
title: "Materialized View"
|
|
sidebarTitle: "Materialized View"
|
|
description: "CREATE MATERIALIZED VIEW and SHOW MATERIALIZED VIEWS; refreshing is a REFRESH statement."
|
|
icon: table
|
|
keywords: ["materialized view", "create materialized view", "show materialized views", "sql"]
|
|
---
|
|
|
|
<Badge color="red">Enterprise</Badge> [SQL runs on a deployment.](/sql)
|
|
|
|
A materialized view stores a query's result as rows, kept current by a refresh
|
|
-- the counterpart to a [view](/sql/ddl/view), which stores only the query.
|
|
|
|
<Note>
|
|
Materialized views are experimental on a deployment, which has to have them
|
|
enabled. Which statements and query shapes a deployment accepts, and how its
|
|
refresh works, depend on its LanceDB Enterprise version and configuration.
|
|
</Note>
|
|
|
|
## CREATE MATERIALIZED VIEW {#create}
|
|
|
|
```sql
|
|
CREATE MATERIALIZED VIEW <name> AS SELECT ...
|
|
```
|
|
|
|
On a `db://` connection, the SDK's
|
|
[`create_materialized_view`](/management/materialized-view#create) sends this
|
|
statement. Once created, a view is queried like a table, refreshed with SQL and
|
|
listed with SQL.
|
|
|
|
## SHOW MATERIALIZED VIEWS {#show}
|
|
|
|
```sql
|
|
SHOW MATERIALIZED VIEWS
|
|
```
|
|
|
|
<Note>
|
|
Cheaper than the SDK equivalent. `list_materialized_views` finds views by
|
|
reading every table's schema, costing one open per table; this asks the server.
|
|
</Note>
|
|
|
|
## Refreshing one {#refresh}
|
|
|
|
```sql
|
|
REFRESH MATERIALIZED VIEW chunks
|
|
```
|
|
|
|
See [REFRESH](/sql/dml/refresh#refresh-materialized-view) for the full syntax,
|
|
including `CASCADE` and `full = true`.
|
|
|
|
## Dropping one {#drop}
|
|
|
|
A materialized view **is** a table, so it is dropped with
|
|
[`DROP TABLE`](/sql/ddl/table#drop) -- which is also why dropping one removes
|
|
stored rows, unlike dropping a [view](/sql/ddl/view#drop).
|
|
|
|
<Note>
|
|
**Enterprise job type:** `mat_view_refresh` for a refresh, or `sql` on a
|
|
deployment that rebuilds views through SQL; `drop_table` for dropping one, same
|
|
as any table.
|
|
</Note>
|
|
|
|
## What to read next {#next}
|
|
|
|
<CardGroup cols={2}>
|
|
<Card title="Materialized View" icon="table" href="/management/materialized-view">
|
|
Creating one from the SDK.
|
|
</Card>
|
|
<Card title="Refresh a materialized view" icon="arrows-rotate" href="/feature-engineering/materialized-views">
|
|
What a refresh recomputes, locally and on a deployment.
|
|
</Card>
|
|
</CardGroup>
|