ClickHouse Refreshable Materialized Views (23.12+) execute queries on a time-based schedule, replacing or appending results atomically. Learn vocabulary for REFRESH EVERY syntax, APPEND mode, the system.view_refreshes monitoring table, manual refresh queuing, and replica coordinator behavior in distributed clusters.
0 / 5 completed
1 / 5
A ClickHouse engineer creates a Refreshable Materialized View with REFRESH EVERY 1 HOUR. How does this differ from a standard Materialized View?
Standard ClickHouse Materialized Views are triggered incrementally on each INSERT to the source table. Refreshable Materialized Views (introduced in ClickHouse 23.12) execute their defining SELECT query on a time-based schedule and atomically replace the entire target table. This enables complex queries with JOINs, subqueries, or external data sources that incremental MVs cannot handle.
2 / 5
A Refreshable MV is running its refresh query when a new REFRESH command is issued manually. What is the default behavior?
By default, ClickHouse queues manual refresh commands — they wait for any in-progress refresh to complete before starting. This prevents concurrent writes to the target table. You can check refresh status via system.view_refreshes to see if a refresh is pending or running.
3 / 5
A Refreshable MV uses APPEND mode. How does this change its refresh behavior?
In APPEND mode, each scheduled refresh inserts new results without truncating the target table. This is useful for accumulating time-series data (e.g., adding hourly snapshots). Without APPEND, each refresh atomically replaces all data in the target table. The APPEND keyword is specified after REFRESH EVERY.
4 / 5
Where can an engineer monitor the status, last refresh time, and next scheduled refresh of all Refreshable MVs in a ClickHouse cluster?
The system.view_refreshes table provides real-time status for all Refreshable Materialized Views: status (Running/Scheduled/Disabled), last_refresh_time, next_refresh_time, last_refresh_result, and exception if the last refresh failed. It is the primary observability tool for refresh scheduling.
5 / 5
A Refreshable MV targets a ReplicatedMergeTree table. On a cluster with 3 replicas, which nodes execute the refresh query?
On a replicated setup, only one replica executes the refresh query (the coordinator, elected via ClickHouse Keeper/ZooKeeper). The resulting data is then replicated to other replicas via the standard ReplicatedMergeTree replication mechanism. This prevents redundant query execution across replicas.