Problem

A number of RDBMS system support Materialized Views, which wikipedia defines thus

In computing, a materialized view is a database object that contains the results of a query. For example, it may be a local copy of data located remotely, or may be a subset of the rows and/or columns of a table or join result, or may be a summary using an aggregate function.

The process of setting up a materialized view is sometimes called materialization. This is a form of caching the results of a query, similar to memoization of the value of a function in functional languages, and it is sometimes described as a form of precomputation. As with other forms of precomputation, database users typically use materialized views for performance reasons, i.e. as a form of optimization.

Materialized views which store data based on remote tables are also known as snapshots.[citation needed] (C. J. Date regards the phrase "materialized view" as a deprecated term for a "snapshot".)

In any database management system following the relational model, a view is a virtual table representing the result of a database query. Whenever a query or an update addresses an ordinary view's virtual table, the DBMS converts these into queries or updates against the underlying base tables. A materialized view takes a different approach: the query result is cached as a concrete ("materialized") table (rather than a view as such) that may be updated from the original base tables from time to time. This enables much more efficient access, at the cost of extra storage and of some data being potentially out-of-date. Materialized views find use especially in data warehousing scenarios, where frequent queries of the actual base tables can be expensive.

In a materialized view, indexes can be built on any column. In contrast, in a normal view, it's typically only possible to exploit indexes on columns that come directly from (or have a mapping to) indexed columns in the base tables; often this functionality is not offered at all.

This ticket is for tracking the potential design & implementation for MariaDB.

Background

Various dialects are support by existing vendors, e.g.

PostgreSQL
https://www.postgresql.org/docs/current/rules-materializedviews.html

CREATE MATERIALIZED VIEW table_name

    [ (column_name [, ...] ) ]

    [ WITH ( storage_parameter [= value] [, ... ] ) ]

    [ TABLESPACE tablespace_name ]

    AS query

    [ WITH [ NO ] DATA ]

Oracle
https://docs.oracle.com/en/database/oracle/oracle-database/23/sqlrf/CREATE-MATERIALIZED-VIEW.html

SQL Server (Materialized and Indexed Views)
https://learn.microsoft.com/en-us/fabric/real-time-intelligence/materialized-view
https://msdn.microsoft.com/en-us/library/ms191432.aspx

Suggested implementation:
CREATE MATERIALIZED VIEW view_name as query ".." should create a table named 'view_name' and fill it with the data.
The table should identify itself as a view:
DROP VIEW should drop the table.
SHOW CREATE VIEW should show the view definition.
Users should have access rights to the view to use it.

REFRESH MATERIALIZED VIEW should update the content of the view (PostgreSQL syntax).
This should be done atomic and in place. This means that the users should have access to the old version of the view until the new
view is in place. When that happens, we should move the new view atomic over the old one.
The swap of views should preferably done 'instant', if possible. This means that there should never be a wait when the replacement happens.
This could for example be done by having the view use a it's own temporary table name internally and move new users to the new file and automatically delete the old temporary table when the last user stops accessing it.

For first version, lets just create view as such.
For next version, allow the user create the view with indexes, with same syntax as in CREATE TABLE.