The Coalesce Materialized View Stage UDN is a versatile Node that allows you to develop and deploy a Materialized View in Snowflake.
A materialized view is a pre-computed data set derived from a query specification (the SELECT in the view definition) and stored for later use. Materialized views can speed up expensive aggregation, projection, and selection operations, especially those that run frequently and that run on large data sets.
The Materialized View Stage has three configuration groups:
There are four configs within the Node Properties group.
| Property | Description |
|---|---|
| Storage Location | Storage Location where the Materialized View will be created |
| Node Type | Name of template used to create node objects |
| Description | A description of the Node's purpose |
| Deploy Enabled | If TRUE the Node will be deployed or redeployed when changes are detected If FALSE the Node will not be deployed or will be dropped during redeployment |
There are two configs within the Materialized View Options group.
| Option | Description |
|---|---|
| Cluster key | True/False to determine whether Materialized view is to be clustered or not - True: Allows you to specify the column based on which clustering is to be done -Allow Expressions Cluster Key: True allows to add an expression to the specified cluster key - False: No clustering done |
| Secure | True / False Toggle to determine whether Materialized view to be created in a secured mode - True: Materialized view created in a secured mode - False: No additional secure option added during Materialized view creation |
| Option | Description |
|---|---|
| Distinct | True / False toggle that specifies whether or not to return DISTINCT rows |
Materialized View has a set of limitations:
- A materialized view cannot query a materialized or non-materialized view
- A materialized view does not support group by all but group by is supported
- A materialized view can query only a single table.
Review Snowflake's Limitations on Creating Materialized Views.
When deployed for the first time into an environment Materialized View will execute three stages:
| Stage | Description |
|---|---|
| Create Materialized View | This stage will execute a CREATE OR REPLACE statement and create a Materialized View in the target environment |
| Applying Materialized View Clustering | This stage will apply clustering to the created Materialized View if Clustering is set to true |
| Resume recluster Materialized View | This stage will resume the Materialized View based on clustering |
After the Materialized View has deployed for the first time into a target environment, subsequent deployments may result in either altering the Materialized View or recreating the Materialized View.
If a Materialized View is to be altered this will run the following stage:
| Stage | Description |
|---|---|
| Alter Materialized View | This stage will execute an ALTER statement and alter the Materialized View in the target environment setting the new parameters |
There are two config changes that if made in isolation or all-together will result in an ALTER statement to modify the Materialized View in the target environment.
- Cluster key
- Secure
If anything changes other than the configuration options specified above then the Materialized View will be recreated by running a CREATE OR REPLACE statement.
If the Nodes are redeployed with no changes compared to previous deployment, then no stages are executed
Node Type switching is supported starting from Coalesce version 7.28+.
From this version onward, a Node's materialization type can be switched from one supported type to another, subject to certain limitations.
For more information, see Node Type Switching Logic and Limitations
If a Materialized View is deleted from a Workspace, that Workspace is committed to Git and that commit deployed to a higher-level Environment, then the Materialized View in the target Environment will be dropped.
This is executed as a single stage:
| Stage | Description |
|---|---|
| Drop Materialized View | Removes the materialized view |
| Current MaterializationType | Desired MaterializationType | Stage |
|---|---|---|
| Materialized View | Materialized View | Follows existing redeployment stage |
| Any Other | Materialized View | 1. Warning (if applicable) 2. Drop 3. Create |
Review the documented limitations before performing a Node type switch to ensure compatibility and avoid unintended deployment issues.
| # | Current Materialization | Desired Materialization | Limitation |
|---|---|---|---|
| 1 | Older Version Iceberg Table | Table | Results in ALTER failure. Iceberg tables require ALTER ICEBERG TABLE. Works only if latest package (with switching support) is already used. |
| 2 | Older Version Create or Alter View | Any | Switch fails unless the current Node uses the latest package that supports Node type switching. |
| 3 | First Node in Pipeline | Any | Not supported. First Node is foundational and switching may disrupt the pipeline. |
| 4 | External Packages | Any | Not supported as they typically act as first Nodes in the pipeline. |
| 5 | Functional Packages | Any | Not supported due to column re-sync behavior which may cause schema inconsistencies. |
| 6 | Dynamic Dimension / LRV | Any | System columns must be manually dropped before redeployment. |
| 7 | Any | Any Other | After performing node switching, the Create/Run in Workspace browser may not work as expected due to changes in the Node's materialization type. |
| 8 | Table(Data Profiling) | Table | This may result in ALTER failure unless latest package is used(with system column removal support)(Pending Release) |