From 1e62b83fb2b6002ac690eae0b71262940bc23bf9 Mon Sep 17 00:00:00 2001 From: Yugo Nagata Date: Fri, 20 Dec 2019 10:25:34 +0900 Subject: [PATCH v29 11/11] Add documentations about Incremental View Maintenance --- doc/src/sgml/catalogs.sgml | 9 + .../sgml/ref/create_materialized_view.sgml | 124 ++++- .../sgml/ref/refresh_materialized_view.sgml | 8 +- doc/src/sgml/rules.sgml | 437 ++++++++++++++++++ doc/src/sgml/system-views.sgml | 9 + 5 files changed, 583 insertions(+), 4 deletions(-) diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml index d17ff51e28..3de3303cac 100644 --- a/doc/src/sgml/catalogs.sgml +++ b/doc/src/sgml/catalogs.sgml @@ -2224,6 +2224,15 @@ SCRAM-SHA-256$<iteration count>:&l + + + relisivm bool + + + True if relation is incrementally maintainable materialized view + + + relrewrite oid diff --git a/doc/src/sgml/ref/create_materialized_view.sgml b/doc/src/sgml/ref/create_materialized_view.sgml index 0d2fea2b97..8c574062db 100644 --- a/doc/src/sgml/ref/create_materialized_view.sgml +++ b/doc/src/sgml/ref/create_materialized_view.sgml @@ -21,7 +21,7 @@ PostgreSQL documentation -CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] table_name +CREATE [ INCREMENTAL ] MATERIALIZED VIEW [ IF NOT EXISTS ] table_name [ (column_name [, ...] ) ] [ USING method ] [ WITH ( storage_parameter [= value] [, ... ] ) ] @@ -60,6 +60,125 @@ CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] table_name Parameters + + INCREMENTAL + + + If specified, some triggers are automatically created so that the rows + of the materialized view are immediately updated when base tables of the + materialized view are updated. In general, this allows faster update of + the materialized view at a price of slower update of the base tables + because the triggers will be invoked. We call this form of materialized + view as "Incrementally Maintainable Materialized View" (IMMV). + + + When IMMV is defined without using WITH NO DATA, + a unique index is created on the view automatically if possible. If the view + definition query has a GROUP BY clause, a unique index is created on the columns + of GROUP BY expressions. Also, if the view has DISTINCT clause, a unique index + is created on all columns in the target list. Otherwise, if the view contains all + primary key attritubes of its base tables in the target list, a unique index is + created on these attritubes. In other cases, no index is created. + + + There are restrictions of query definitions allowed to use this + option. The following are supported in query definitions for IMMV: + + + + + Inner joins (including self-joins). + + + + + + Some built-in aggregate functions (count, sum, avg, min, max) without a HAVING + clause. + + + + + Unsupported queries with this option include the following: + + + + + Outer joins. + + + + + + Sub-queries. + + + + + + Aggregate functions other than built-in count, sum, avg, min and max. + + + + + Aggregate functions with a HAVING clause. + + + + + DISTINCT ON, WINDOW, VALUES, LIMIT and OFFSET clause. + + + + + Other restrictions include: + + + + + IMMVs must be based on simple base tables. It's not supported to + create them on top of views or materialized views. + + + + + + It is not supported to include system columns in an IMMV. + +CREATE INCREMENTAL MATERIALIZED VIEW mv_ivm02 AS SELECT i,j FROM mv_base_a WHERE xmin = '610'; +ERROR: system column is not supported with IVM + + + + + + + Non-immutable functions are not supported. + +CREATE INCREMENTAL MATERIALIZED VIEW mv_ivm12 AS SELECT i,j FROM mv_base_a WHERE i = random()::int; +ERROR: functions in IMMV must be marked IMMUTABLE + + + + + + + IMMVs do not support expressions that contains aggregates + + + + + + Logical replication does not support IMMVs. + + + + + + + + + IF NOT EXISTS @@ -155,7 +274,8 @@ CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] table_name This clause specifies whether or not the materialized view should be populated at creation time. If not, the materialized view will be flagged as unscannable and cannot be queried until REFRESH - MATERIALIZED VIEW is used. + MATERIALIZED VIEW is used. Also, if the view is IMMV, + triggers for maintaining the view are not created. diff --git a/doc/src/sgml/ref/refresh_materialized_view.sgml b/doc/src/sgml/ref/refresh_materialized_view.sgml index 675d6090f3..c29cfc19b6 100644 --- a/doc/src/sgml/ref/refresh_materialized_view.sgml +++ b/doc/src/sgml/ref/refresh_materialized_view.sgml @@ -35,9 +35,13 @@ REFRESH MATERIALIZED VIEW [ CONCURRENTLY ] nameWITH DATA is specified (or defaults) the backing query is executed to provide the new data, and the materialized view is left in a - scannable state. If WITH NO DATA is specified no new + scannable state. If the view is an incrementally maintainable materialized + view (IMMV) and was unpopulated, triggers for maintaining the view are + created. Also, a unique index is created for IMMV if it is possible and the + view doesn't have that yet. + If WITH NO DATA is specified no new data is generated and the materialized view is left in an unscannable - state. + state. If the view is IMMV, the triggers are dropped. CONCURRENTLY and WITH NO DATA may not diff --git a/doc/src/sgml/rules.sgml b/doc/src/sgml/rules.sgml index d229b94d39..22e4cad103 100644 --- a/doc/src/sgml/rules.sgml +++ b/doc/src/sgml/rules.sgml @@ -1096,6 +1096,443 @@ SELECT word FROM words ORDER BY word <-> 'caterpiler' LIMIT 10; + +Incremental View Maintenance + + + incremental view maintenance + + + + materialized view + incremental view maintenance + + + + view + incremental view maintenance + + + +Overview + + + Incremental View Maintenance (IVM) is a way to make + materialized views up-to-date in which only incremental changes are computed + and applied on views rather than recomputing the contents from scratch as + REFRESH MATERIALIZED VIEW does. IVM + can update materialized views more efficiently than recomputation when only + small parts of the view are changed. + + + + There are two approaches with regard to timing of view maintenance: + immediate and deferred. In immediate maintenance, views are updated in the + same transaction that its base table is modified. In deferred maintenance, + views are updated after the transaction is committed, for example, when the + view is accessed, as a response to user command like REFRESH + MATERIALIZED VIEW, or periodically in background, and so on. + PostgreSQL currently implements only a kind of + immediate maintenance, in which materialized views are updated immediately + in AFTER triggers when a base table is modified. + + + + To create materialized views supporting IVM, use the + CREATE INCREMENTAL MATERIALIZED VIEW, for example: + +CREATE INCREMENTAL MATERIALIZED VIEW mymatview AS SELECT * FROM mytab; + + When a materialized view is created with the INCREMENTAL + keyword, some triggers are automatically created so that the view's contents are + immediately updated when its base tables are modified. We call this form + of materialized view an Incrementally Maintainable Materialized View + (IMMV). + +postgres=# CREATE INCREMENTAL MATERIALIZED VIEW m AS SELECT * FROM t0; +NOTICE: could not create an index on materialized view "m" automatically +HINT: Create an index on the materialized view for effcient incremental maintenance. +SELECT 3 +postgres=# SELECT * FROM m; + i +--- + 1 + 2 + 3 +(3 rows) + +postgres=# INSERT INTO t0 VALUES (4); +INSERT 0 1 +postgres=# SELECT * FROM m; -- automatically updated + i +--- + 1 + 2 + 3 + 4 +(4 rows) + + + + + Some IMMVs have hidden columns which are added + automatically when a materialized view is created. Their name starts + with __ivm_ and they contain information required + for maintaining the IMMV. Such columns are not visible + when the IMMV is accessed by SELECT * + but are visible if the column name is explicitly specified in the target + list. We can also see the hidden columns in \d + meta-commands of psql commands. + + + + In general, IMMVs allow faster updates of materialized + views at the price of slower updates to their base tables. Updates of + IMMV is slower because triggers will be invoked and the + view is updated in triggers per modification statement. + + + + For example, suppose a normal materialized view defined as below: + + +test=# CREATE INCREMENTAL MATERIALIZED VIEW mv_ivm AS + SELECT a.aid, b.bid, a.abalance, b.bbalance + FROM pgbench_accounts a JOIN pgbench_branches b USING(bid); +SELECT 10000000 + + + + Updating a tuple in a base table of this materialized view is rapid but the + REFRESH MATERIALIZED VIEW command on this view takes a long time: + + +test=# UPDATE pgbench_accounts SET abalance = 1000 WHERE aid = 1; +UPDATE 1 +Time: 0.990 ms + +test=# REFRESH MATERIALIZED VIEW mv_normal ; +REFRESH MATERIALIZED VIEW +Time: 33533.952 ms (00:33.534) + + + + + On the other hand, after creating IMMV with the same view + definition as below: + + +test=# CREATE INCREMENTAL MATERIALIZED VIEW mv_ivm AS + SELECT a.aid, b.bid, a.abalance, b.bbalance + FROM pgbench_accounts a JOIN pgbench_branches b USING(bid); +test=# UPDATE pgbench_accounts SET abalance = 1000 WHERE aid = 1; +NOTICE: created index "mv_ivm_index" on materialized view "mv_ivm" + + + updating a tuple in a base table takes more than the normal view, + but its content is updated automatically and this is faster than the + REFRESH MATERIALIZED VIEW command. + + +test=# UPDATE pgbench_accounts SET abalance = 1000 WHERE aid = 1; +UPDATE 1 +Time: 13.068 ms + + + + + + Appropriate indexes on IMMVs are necessary for + efficient IVM because it looks for tuples to be + updated in IMMV. If there are no indexes, it + will take a long time. + + + + Therefore, when IMMV is defined, a unique index is created on the view + automatically if possible. If the view definition query has a GROUP BY clause, a unique + index is created on the columns of GROUP BY expressions. Also, if the view has DISTINCT + clause, a unique index is created on all columns in the target list. Otherwise, if the + view contains all primary key attritubes of its base tables in the target list, a unique + index is created on these attritubes. In other cases, no index is created. + + + + In the previous example, a unique index "mv_ivm_index" is created on aid and bid + columns of materialized view "mv_ivm", and this enables the rapid update of the view. + Dropping this index make updating the view take a loger time. + +test=# DROP INDEX mv_ivm_index; +DROP INDEX +Time: 67.081 ms + +test=# UPDATE pgbench_accounts SET abalance = 1000 WHERE aid = 1; +UPDATE 1 +Time: 16386.245 ms (00:16.386) + + + + + + IVM is effective when we want to keep a materialized + view up-to-date and small fraction of a base table is modified + infrequently. Due to the overhead of immediate maintenance, IVM + is not effective when a base table is modified frequently. Also, when a + large part of a base table is modified or large data is inserted into a + base table, IVM is not effective and the cost of + maintenance can be larger than the REFRESH MATERIALIZED VIEW + command. In such situation, we can use REFRESH MATERIALIZED VIEW + and specify WITH NO DATA to disable immediate + maintenance before modifying a base table. After a base table modification, + execute the REFRESH MATERIALIZED VIEW (with WITH DATA) + command to refresh the view data and enable immediate maintenance. + + + + + +Supported View Definitions and Restrictions + + + Currently, we can create IMMVs using inner joins, and some + aggregates. However, several restrictions apply to the definition of IMMV. + + + +Joins + + Inner joins including self-join are supported. Outer joins are not supported. + + + + +Aggregates + + Supported aggregate functions are count, sum, + avg, min, and max. + Currently, only built-in aggregate functions are supported and user defined + aggregates cannot be used. When a base table is modified, the new aggregated + values are incrementally calculated using the old aggregated values and values + of related hidden columns stored in IMMV. + + + + Note that for min or max, the new values + could be re-calculated from base tables with regard to the affected groups when a + tuple containing the current minimal or maximal values are deleted from a base table. + Therefore, it can takes a long time to update an IMMV containing + these functions. + + + + Also note that using sum or avg on + real (float4) type or double precision + (float8) type in IMMV is unsafe. This is + because aggregated values in IMMV can become different from + results calculated from base tables due to the limited precision of these types. + To avoid this problem, use the numeric type instead. + + + + Restrictions on Aggregates + + There are the following restrictions: + + + + If we have a GROUP BY clause, expressions specified in + GROUP BY must appear in the target list. This is + how tuples to be updated in the IMMV are identified. + These attributes are used as scan keys for searching tuples in the + IMMV, so indexes on them are required for efficient + IVM. + + + + + + HAVING clause cannot be used. + + + + + + + + +Other General Restrictions + + There are other restrictions which generally apply to IMMV: + + + + Sub-queries cannot be used. + + + + + + CTEs cannot be used. + + + + + + Window functions cannot be used. + + + + + + IMMVs must be based on simple base tables. It's not + supported to create them on top of views, materialized views, foreign tables, inhe. + + + + + + LIMIT and OFFSET clauses cannot be used. + + + + + + IMMVs cannot contain system columns. + + + + + + IMMVs cannot contain non-immutable functions. + + + + + + UNION/INTERSECT/EXCEPT clauses cannnot be used. + + + + + + DISTINCT ON clauses cannot be used. + + + + + + TABLESAMPLE parameter cannot be used. + + + + + + inheritance parent tables cannnot be used. + + + + + + VALUES clause cannnot be used. + + + + + + GROUPING SETS and FILTER clauses cannot be used. + + + + + + FOR UPDATE/SHARE cannot be used. + + + + + + targetlist cannot contain columns whose name start with __ivm_. + + + + + + targetlist cannot contain expressions which contain an aggregate in it. + + + + + + Logical replication is not supported, that is, even when a base table + at a publisher node is modified, IMMVs at subscriber + nodes are not updated. + + + + + + + + + + +<literal>DISTINCT</literal> + + + PostgreSQL supports IMMV with + DISTINCT. For example, suppose a IMMV + defined with DISTINCT on a base table containing duplicate + tuples. When tuples are deleted from the base table, a tuple in the view is + deleted if and only if the multiplicity of the tuple becomes zero. Moreover, + when tuples are inserted into the base table, a tuple is inserted into the + view only if the same tuple doesn't already exist in it. + + + + Physically, an IMMV defined with DISTINCT + contains tuples after eliminating duplicates, and the multiplicity of each tuple + is stored in a hidden column named __ivm_count__. + + + + +Concurrent Transactions + + Suppose an IMMV is defined on two base tables and each + table was modified in different a concurrent transaction simultaneously. + In the transaction which was committed first, IMMV can + be updated considering only the change which happened in this transaction. + On the other hand, in order to update the view correctly in the transaction + which was committed later, we need to know the changes occurred in + both transactions. For this reason, ExclusiveLock + is held on an IMMV immediately after a base table is + modified in READ COMMITTED mode to make sure that + the IMMV is updated in the latter transaction after + the former transaction is committed. In REPEATABLE READ + or SERIALIZABLE mode, an error is raised immediately + if lock acquisition fails because any changes which occurred in + other transactions are not be visible in these modes and + IMMV cannot be updated correctly in such situations. + However, as an exception if the view has only one base table and + INSERT is performed on the table, + the lock held on thew view is RowExclusiveLock. + + + + +Row Level Security + + If some base tables have row level security policy, rows that are not visible + to the materialized view's owner are excluded from the result. In addition, such + rows are excluded as well when views are incrementally maintained. However, if a + new policy is defined or policies are changed after the materialized view was created, + the new policy will not be applied to the view contents. To apply the new policy, + you need to refresh materialized views. + + + + + Rules on <command>INSERT</command>, <command>UPDATE</command>, and <command>DELETE</command> diff --git a/doc/src/sgml/system-views.sgml b/doc/src/sgml/system-views.sgml index 2b35c2f91b..5366f707eb 100644 --- a/doc/src/sgml/system-views.sgml +++ b/doc/src/sgml/system-views.sgml @@ -1787,6 +1787,15 @@ SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx + + + isimmv bool + + + True if materialized view is incrementally maintainable + + + definition text -- 2.25.1