($INBOX_DIR/description missing)help / color / mirror / Atom feed
[PATCH v38 11/11] Add documentations about Incremental View Maintenance 22+ messages / 2 participants [nested] [flat]
* [PATCH v38 11/11] Add documentations about Incremental View Maintenance @ 2019-12-20 01:25 Yugo Nagata <[email protected]> 0 siblings, 0 replies; 22+ messages in thread From: Yugo Nagata @ 2019-12-20 01:25 UTC (permalink / raw) --- 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 4b474c13917..9b1c88161a7 100644 --- a/doc/src/sgml/catalogs.sgml +++ b/doc/src/sgml/catalogs.sgml @@ -2276,6 +2276,15 @@ SCRAM-SHA-256$<replaceable><iteration count></replaceable>:<replaceable>&l </para></entry> </row> + <row> + <entry role="catalog_table_entry"><para role="column_definition"> + <structfield>relisivm</structfield> <type>bool</type> + </para> + <para> + True if relation is incrementally maintainable materialized view + </para></entry> + </row> + <row> <entry role="catalog_table_entry"><para role="column_definition"> <structfield>relrewrite</structfield> <type>oid</type> diff --git a/doc/src/sgml/ref/create_materialized_view.sgml b/doc/src/sgml/ref/create_materialized_view.sgml index 62d897931c3..f49db209558 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 <refsynopsisdiv> <synopsis> -CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> +CREATE [ INCREMENTAL ] MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> [ (<replaceable>column_name</replaceable> [, ...] ) ] [ USING <replaceable class="parameter">method</replaceable> ] [ WITH ( <replaceable class="parameter">storage_parameter</replaceable> [= <replaceable class="parameter">value</replaceable>] [, ... ] ) ] @@ -60,6 +60,125 @@ CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> <title>Parameters</title> <variablelist> + <varlistentry> + <term><literal>INCREMENTAL</literal></term> + <listitem> + <para> + 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). + </para> + <para> + When <acronym>IMMV</acronym> is defined without using <command>WITH NO DATA</command>, + 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. + </para> + <para> + There are restrictions of query definitions allowed to use this + option. The following are supported in query definitions for IMMV: + <itemizedlist> + + <listitem> + <para> + Inner joins (including self-joins). + </para> + </listitem> + + <listitem> + <para> + Some built-in aggregate functions (count, sum, avg, min, max) without a HAVING + clause. + </para> + </listitem> + </itemizedlist> + + Unsupported queries with this option include the following: + + <itemizedlist> + <listitem> + <para> + Outer joins. + </para> + </listitem> + + <listitem> + <para> + Sub-queries. + </para> + </listitem> + + <listitem> + <para> + Aggregate functions other than built-in count, sum, avg, min and max. + </para> + </listitem> + <listitem> + <para> + Aggregate functions with a HAVING clause. + </para> + </listitem> + <listitem> + <para> + DISTINCT ON, WINDOW, VALUES, LIMIT and OFFSET clause. + </para> + </listitem> + </itemizedlist> + + Other restrictions include: + <itemizedlist> + + <listitem> + <para> + IMMVs must be based on simple base tables. It's not supported to + create them on top of views or materialized views. + </para> + </listitem> + + <listitem> + <para> + It is not supported to include system columns in an IMMV. + <programlisting> +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 + </programlisting> + </para> + </listitem> + + <listitem> + <para> + Non-immutable functions are not supported. + <programlisting> +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 + </programlisting> + </para> + </listitem> + + <listitem> + <para> + IMMVs do not support expressions that contains aggregates + </para> + </listitem> + + <listitem> + <para> + Logical replication does not support IMMVs. + </para> + </listitem> + + </itemizedlist> + + </para> + </listitem> + </varlistentry> + <varlistentry> <term><literal>IF NOT EXISTS</literal></term> <listitem> @@ -157,7 +276,8 @@ CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> 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 <command>REFRESH - MATERIALIZED VIEW</command> is used. + MATERIALIZED VIEW</command> is used. Also, if the view is IMMV, + triggers for maintaining the view are not created. </para> </listitem> </varlistentry> diff --git a/doc/src/sgml/ref/refresh_materialized_view.sgml b/doc/src/sgml/ref/refresh_materialized_view.sgml index 8ed43ade803..a4d729bdf0f 100644 --- a/doc/src/sgml/ref/refresh_materialized_view.sgml +++ b/doc/src/sgml/ref/refresh_materialized_view.sgml @@ -36,9 +36,13 @@ REFRESH MATERIALIZED VIEW [ CONCURRENTLY ] <replaceable class="parameter">name</ privilege on the materialized view. The old contents are discarded. If <literal>WITH DATA</literal> 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 <literal>WITH NO DATA</literal> 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 <literal>WITH NO DATA</literal> 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. </para> <para> <literal>CONCURRENTLY</literal> and <literal>WITH NO DATA</literal> may not diff --git a/doc/src/sgml/rules.sgml b/doc/src/sgml/rules.sgml index 7f23962f524..da9ad3c6316 100644 --- a/doc/src/sgml/rules.sgml +++ b/doc/src/sgml/rules.sgml @@ -1103,6 +1103,443 @@ SELECT word FROM words ORDER BY word <-> 'caterpiler' LIMIT 10; </sect1> +<sect1 id="rules-ivm"> +<title>Incremental View Maintenance</title> + +<indexterm zone="rules-ivm"> + <primary>incremental view maintenance</primary> +</indexterm> + +<indexterm zone="rules-ivm"> + <primary>materialized view</primary> + <secondary>incremental view maintenance</secondary> +</indexterm> + +<indexterm zone="rules-ivm"> + <primary>view</primary> + <secondary>incremental view maintenance</secondary> +</indexterm> + +<sect2 id="rules-ivm-overview"> +<title>Overview</title> + +<para> + Incremental View Maintenance (<acronym>IVM</acronym>) 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 + <command>REFRESH MATERIALIZED VIEW</command> does. <acronym>IVM</acronym> + can update materialized views more efficiently than recomputation when only + small parts of the view are changed. +</para> + +<para> + 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 <command>REFRESH + MATERIALIZED VIEW</command>, or periodically in background, and so on. + <productname>PostgreSQL</productname> currently implements only a kind of + immediate maintenance, in which materialized views are updated immediately + in AFTER triggers when a base table is modified. +</para> + +<para> + To create materialized views supporting <acronym>IVM</acronym>, use the + <command>CREATE INCREMENTAL MATERIALIZED VIEW</command>, for example: +<programlisting> +CREATE <emphasis>INCREMENTAL</emphasis> MATERIALIZED VIEW mymatview AS SELECT * FROM mytab; +</programlisting> + When a materialized view is created with the <literal>INCREMENTAL</literal> + 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 + (<acronym>IMMV</acronym>). +<programlisting> +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) +</programlisting> +</para> + +<para> + Some <acronym>IMMV</acronym>s have hidden columns which are added + automatically when a materialized view is created. Their name starts + with <literal>__ivm_</literal> and they contain information required + for maintaining the <acronym>IMMV</acronym>. Such columns are not visible + when the <acronym>IMMV</acronym> is accessed by <literal>SELECT *</literal> + but are visible if the column name is explicitly specified in the target + list. We can also see the hidden columns in <literal>\d</literal> + meta-commands of <command>psql</command> commands. +</para> + +<para> + In general, <acronym>IMMV</acronym>s allow faster updates of materialized + views at the price of slower updates to their base tables. Updates of + <acronym>IMMV</acronym> is slower because triggers will be invoked and the + view is updated in triggers per modification statement. +</para> + +<para> + For example, suppose a normal materialized view defined as below: + +<programlisting> +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 + +</programlisting> + + Updating a tuple in a base table of this materialized view is rapid but the + <command>REFRESH MATERIALIZED VIEW</command> command on this view takes a long time: + +<programlisting> +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) +</programlisting> +</para> + +<para> + On the other hand, after creating <acronym>IMMV</acronym> with the same view + definition as below: + +<programlisting> +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" +</programlisting> + + 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 + <command>REFRESH MATERIALIZED VIEW</command> command. + +<programlisting> +test=# UPDATE pgbench_accounts SET abalance = 1000 WHERE aid = 1; +UPDATE 1 +Time: 13.068 ms +</programlisting> + +</para> + +<para> + Appropriate indexes on <acronym>IMMV</acronym>s are necessary for + efficient <acronym>IVM</acronym> because it looks for tuples to be + updated in <acronym>IMMV</acronym>. If there are no indexes, it + will take a long time. +</para> + +<para> + Therefore, when <acronym>IMMV</acronym> 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. +</para> + +<para> + 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. +<programlisting> +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) +</programlisting> + +</para> + +<para> + <acronym>IVM</acronym> 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, <acronym>IVM</acronym> + 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, <acronym>IVM</acronym> is not effective and the cost of + maintenance can be larger than the <command>REFRESH MATERIALIZED VIEW</command> + command. In such situation, we can use <command>REFRESH MATERIALIZED VIEW</command> + and specify <literal>WITH NO DATA</literal> to disable immediate + maintenance before modifying a base table. After a base table modification, + execute the <command>REFRESH MATERIALIZED VIEW</command> (with <literal>WITH DATA</literal>) + command to refresh the view data and enable immediate maintenance. +</para> + +</sect2> + +<sect2 id="rules-ivm-support"> +<title>Supported View Definitions and Restrictions</title> + +<para> + Currently, we can create <acronym>IMMV</acronym>s using inner joins, and some + aggregates. However, several restrictions apply to the definition of IMMV. +</para> + +<sect3 id="rules-ivm-support-joins"> +<title>Joins</title> +<para> + Inner joins including self-join are supported. Outer joins are not supported. +</para> +</sect3> + +<sect3 id="rules-ivm-support-aggregates"> +<title>Aggregates</title> +<para> + Supported aggregate functions are <function>count</function>, <function>sum</function>, + <function>avg</function>, <function>min</function>, and <function>max</function>. + 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 <acronym>IMMV</acronym>. +</para> + +<para> + Note that for <function>min</function> or <function>max</function>, 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 <acronym>IMMV</acronym> containing + these functions. +</para> + +<para> + Also note that using <function>sum</function> or <function>avg</function> on + <type>real</type> (<type>float4</type>) type or <type>double precision</type> + (<type>float8</type>) type in <acronym>IMMV</acronym> is unsafe. This is + because aggregated values in <acronym>IMMV</acronym> can become different from + results calculated from base tables due to the limited precision of these types. + To avoid this problem, use the <type>numeric</type> type instead. +</para> + + <sect4 id="rules-ivm-restrictions-aggregates"> + <title>Restrictions on Aggregates</title> + <para> + There are the following restrictions: + <itemizedlist> + <listitem> + <para> + If we have a <literal>GROUP BY</literal> clause, expressions specified in + <literal>GROUP BY</literal> must appear in the target list. This is + how tuples to be updated in the <acronym>IMMV</acronym> are identified. + These attributes are used as scan keys for searching tuples in the + <acronym>IMMV</acronym>, so indexes on them are required for efficient + <acronym>IVM</acronym>. + </para> + </listitem> + + <listitem> + <para> + <literal>HAVING</literal> clause cannot be used. + </para> + </listitem> + </itemizedlist> + </para> + </sect4> +</sect3> + +<sect3 id="rules-ivm-general-restricitons"> +<title>Other General Restrictions</title> +<para> + There are other restrictions which generally apply to <acronym>IMMV</acronym>: + <itemizedlist> + <listitem> + <para> + Sub-queries cannot be used. + </para> + </listitem> + + <listitem> + <para> + CTEs cannot be used. + </para> + </listitem> + + <listitem> + <para> + Window functions cannot be used. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s must be based on simple base tables. It's not + supported to create them on top of views, materialized views, foreign tables, inhe. + </para> + </listitem> + + <listitem> + <para> + LIMIT and OFFSET clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s cannot contain system columns. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s cannot contain non-immutable functions. + </para> + </listitem> + + <listitem> + <para> + UNION/INTERSECT/EXCEPT clauses cannnot be used. + </para> + </listitem> + + <listitem> + <para> + DISTINCT ON clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + TABLESAMPLE parameter cannot be used. + </para> + </listitem> + + <listitem> + <para> + inheritance parent tables cannnot be used. + </para> + </listitem> + + <listitem> + <para> + VALUES clause cannnot be used. + </para> + </listitem> + + <listitem> + <para> + <literal>GROUPING SETS</literal> and <literal>FILTER</literal> clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + FOR UPDATE/SHARE cannot be used. + </para> + </listitem> + + <listitem> + <para> + targetlist cannot contain columns whose name start with <literal>__ivm_</literal>. + </para> + </listitem> + + <listitem> + <para> + targetlist cannot contain expressions which contain an aggregate in it. + </para> + </listitem> + + <listitem> + <para> + Logical replication is not supported, that is, even when a base table + at a publisher node is modified, <acronym>IMMV</acronym>s at subscriber + nodes are not updated. + </para> + </listitem> + + </itemizedlist> +</para> +</sect3> + +</sect2> + +<sect2 id="rules-ivm-distinct"> +<title><literal>DISTINCT</literal></title> + +<para> + <productname>PostgreSQL</productname> supports <acronym>IMMV</acronym> with + <literal>DISTINCT</literal>. For example, suppose a <acronym>IMMV</acronym> + defined with <literal>DISTINCT</literal> 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. +</para> + +<para> + Physically, an <acronym>IMMV</acronym> defined with <literal>DISTINCT</literal> + contains tuples after eliminating duplicates, and the multiplicity of each tuple + is stored in a hidden column named <literal>__ivm_count__</literal>. +</para> +</sect2> + +<sect2 id="rules-ivm-concurrent-transactions"> +<title>Concurrent Transactions</title> +<para> + Suppose an <acronym>IMMV</acronym> is defined on two base tables and each + table was modified in different a concurrent transaction simultaneously. + In the transaction which was committed first, <acronym>IMMV</acronym> 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, <literal>ExclusiveLock</literal> + is held on an <acronym>IMMV</acronym> immediately after a base table is + modified in <literal>READ COMMITTED</literal> mode to make sure that + the <acronym>IMMV</acronym> is updated in the latter transaction after + the former transaction is committed. In <literal>REPEATABLE READ</literal> + or <literal>SERIALIZABLE</literal> 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 + <acronym>IMMV</acronym> cannot be updated correctly in such situations. + However, as an exception if the view has only one base table and + <command>INSERT</command> is performed on the table, + the lock held on thew view is <literal>RowExclusiveLock</literal>. +</para> +</sect2> + +<sect2 id="rules-ivm-rls"> +<title>Row Level Security</title> +<para> + 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. +</para> +</sect2> + +</sect1> + <sect1 id="rules-update"> <title>Rules on <command>INSERT</command>, <command>UPDATE</command>, and <command>DELETE</command></title> diff --git a/doc/src/sgml/system-views.sgml b/doc/src/sgml/system-views.sgml index 2ebec6928d5..65d1e2041d2 100644 --- a/doc/src/sgml/system-views.sgml +++ b/doc/src/sgml/system-views.sgml @@ -2231,6 +2231,15 @@ SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx </para></entry> </row> + <row> + <entry role="catalog_table_entry"><para role="column_definition"> + <structfield>isimmv</structfield> <type>bool</type> + </para> + <para> + True if materialized view is incrementally maintainable + </para></entry> + </row> + <row> <entry role="catalog_table_entry"><para role="column_definition"> <structfield>definition</structfield> <type>text</type> -- 2.43.0 --Multipart=_Wed__1_Jul_2026_00_04_01_+0900_OVSy2WWK_9aByzDJ Content-Type: text/x-diff; name="v38-0010-Add-regression-tests-for-Incremental-View-Mainte.patch" Content-Disposition: attachment; filename="v38-0010-Add-regression-tests-for-Incremental-View-Mainte.patch" Content-Transfer-Encoding: 7bit ^ permalink raw reply [nested|flat] 22+ messages in thread
* [PATCH v37 11/11] Add documentations about Incremental View Maintenance @ 2019-12-20 01:25 Yugo Nagata <[email protected]> 0 siblings, 0 replies; 22+ messages in thread From: Yugo Nagata @ 2019-12-20 01:25 UTC (permalink / raw) --- 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 4b474c13917..9b1c88161a7 100644 --- a/doc/src/sgml/catalogs.sgml +++ b/doc/src/sgml/catalogs.sgml @@ -2276,6 +2276,15 @@ SCRAM-SHA-256$<replaceable><iteration count></replaceable>:<replaceable>&l </para></entry> </row> + <row> + <entry role="catalog_table_entry"><para role="column_definition"> + <structfield>relisivm</structfield> <type>bool</type> + </para> + <para> + True if relation is incrementally maintainable materialized view + </para></entry> + </row> + <row> <entry role="catalog_table_entry"><para role="column_definition"> <structfield>relrewrite</structfield> <type>oid</type> diff --git a/doc/src/sgml/ref/create_materialized_view.sgml b/doc/src/sgml/ref/create_materialized_view.sgml index 62d897931c3..f49db209558 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 <refsynopsisdiv> <synopsis> -CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> +CREATE [ INCREMENTAL ] MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> [ (<replaceable>column_name</replaceable> [, ...] ) ] [ USING <replaceable class="parameter">method</replaceable> ] [ WITH ( <replaceable class="parameter">storage_parameter</replaceable> [= <replaceable class="parameter">value</replaceable>] [, ... ] ) ] @@ -60,6 +60,125 @@ CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> <title>Parameters</title> <variablelist> + <varlistentry> + <term><literal>INCREMENTAL</literal></term> + <listitem> + <para> + 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). + </para> + <para> + When <acronym>IMMV</acronym> is defined without using <command>WITH NO DATA</command>, + 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. + </para> + <para> + There are restrictions of query definitions allowed to use this + option. The following are supported in query definitions for IMMV: + <itemizedlist> + + <listitem> + <para> + Inner joins (including self-joins). + </para> + </listitem> + + <listitem> + <para> + Some built-in aggregate functions (count, sum, avg, min, max) without a HAVING + clause. + </para> + </listitem> + </itemizedlist> + + Unsupported queries with this option include the following: + + <itemizedlist> + <listitem> + <para> + Outer joins. + </para> + </listitem> + + <listitem> + <para> + Sub-queries. + </para> + </listitem> + + <listitem> + <para> + Aggregate functions other than built-in count, sum, avg, min and max. + </para> + </listitem> + <listitem> + <para> + Aggregate functions with a HAVING clause. + </para> + </listitem> + <listitem> + <para> + DISTINCT ON, WINDOW, VALUES, LIMIT and OFFSET clause. + </para> + </listitem> + </itemizedlist> + + Other restrictions include: + <itemizedlist> + + <listitem> + <para> + IMMVs must be based on simple base tables. It's not supported to + create them on top of views or materialized views. + </para> + </listitem> + + <listitem> + <para> + It is not supported to include system columns in an IMMV. + <programlisting> +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 + </programlisting> + </para> + </listitem> + + <listitem> + <para> + Non-immutable functions are not supported. + <programlisting> +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 + </programlisting> + </para> + </listitem> + + <listitem> + <para> + IMMVs do not support expressions that contains aggregates + </para> + </listitem> + + <listitem> + <para> + Logical replication does not support IMMVs. + </para> + </listitem> + + </itemizedlist> + + </para> + </listitem> + </varlistentry> + <varlistentry> <term><literal>IF NOT EXISTS</literal></term> <listitem> @@ -157,7 +276,8 @@ CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> 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 <command>REFRESH - MATERIALIZED VIEW</command> is used. + MATERIALIZED VIEW</command> is used. Also, if the view is IMMV, + triggers for maintaining the view are not created. </para> </listitem> </varlistentry> diff --git a/doc/src/sgml/ref/refresh_materialized_view.sgml b/doc/src/sgml/ref/refresh_materialized_view.sgml index 8ed43ade803..a4d729bdf0f 100644 --- a/doc/src/sgml/ref/refresh_materialized_view.sgml +++ b/doc/src/sgml/ref/refresh_materialized_view.sgml @@ -36,9 +36,13 @@ REFRESH MATERIALIZED VIEW [ CONCURRENTLY ] <replaceable class="parameter">name</ privilege on the materialized view. The old contents are discarded. If <literal>WITH DATA</literal> 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 <literal>WITH NO DATA</literal> 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 <literal>WITH NO DATA</literal> 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. </para> <para> <literal>CONCURRENTLY</literal> and <literal>WITH NO DATA</literal> may not diff --git a/doc/src/sgml/rules.sgml b/doc/src/sgml/rules.sgml index 7f23962f524..da9ad3c6316 100644 --- a/doc/src/sgml/rules.sgml +++ b/doc/src/sgml/rules.sgml @@ -1103,6 +1103,443 @@ SELECT word FROM words ORDER BY word <-> 'caterpiler' LIMIT 10; </sect1> +<sect1 id="rules-ivm"> +<title>Incremental View Maintenance</title> + +<indexterm zone="rules-ivm"> + <primary>incremental view maintenance</primary> +</indexterm> + +<indexterm zone="rules-ivm"> + <primary>materialized view</primary> + <secondary>incremental view maintenance</secondary> +</indexterm> + +<indexterm zone="rules-ivm"> + <primary>view</primary> + <secondary>incremental view maintenance</secondary> +</indexterm> + +<sect2 id="rules-ivm-overview"> +<title>Overview</title> + +<para> + Incremental View Maintenance (<acronym>IVM</acronym>) 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 + <command>REFRESH MATERIALIZED VIEW</command> does. <acronym>IVM</acronym> + can update materialized views more efficiently than recomputation when only + small parts of the view are changed. +</para> + +<para> + 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 <command>REFRESH + MATERIALIZED VIEW</command>, or periodically in background, and so on. + <productname>PostgreSQL</productname> currently implements only a kind of + immediate maintenance, in which materialized views are updated immediately + in AFTER triggers when a base table is modified. +</para> + +<para> + To create materialized views supporting <acronym>IVM</acronym>, use the + <command>CREATE INCREMENTAL MATERIALIZED VIEW</command>, for example: +<programlisting> +CREATE <emphasis>INCREMENTAL</emphasis> MATERIALIZED VIEW mymatview AS SELECT * FROM mytab; +</programlisting> + When a materialized view is created with the <literal>INCREMENTAL</literal> + 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 + (<acronym>IMMV</acronym>). +<programlisting> +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) +</programlisting> +</para> + +<para> + Some <acronym>IMMV</acronym>s have hidden columns which are added + automatically when a materialized view is created. Their name starts + with <literal>__ivm_</literal> and they contain information required + for maintaining the <acronym>IMMV</acronym>. Such columns are not visible + when the <acronym>IMMV</acronym> is accessed by <literal>SELECT *</literal> + but are visible if the column name is explicitly specified in the target + list. We can also see the hidden columns in <literal>\d</literal> + meta-commands of <command>psql</command> commands. +</para> + +<para> + In general, <acronym>IMMV</acronym>s allow faster updates of materialized + views at the price of slower updates to their base tables. Updates of + <acronym>IMMV</acronym> is slower because triggers will be invoked and the + view is updated in triggers per modification statement. +</para> + +<para> + For example, suppose a normal materialized view defined as below: + +<programlisting> +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 + +</programlisting> + + Updating a tuple in a base table of this materialized view is rapid but the + <command>REFRESH MATERIALIZED VIEW</command> command on this view takes a long time: + +<programlisting> +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) +</programlisting> +</para> + +<para> + On the other hand, after creating <acronym>IMMV</acronym> with the same view + definition as below: + +<programlisting> +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" +</programlisting> + + 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 + <command>REFRESH MATERIALIZED VIEW</command> command. + +<programlisting> +test=# UPDATE pgbench_accounts SET abalance = 1000 WHERE aid = 1; +UPDATE 1 +Time: 13.068 ms +</programlisting> + +</para> + +<para> + Appropriate indexes on <acronym>IMMV</acronym>s are necessary for + efficient <acronym>IVM</acronym> because it looks for tuples to be + updated in <acronym>IMMV</acronym>. If there are no indexes, it + will take a long time. +</para> + +<para> + Therefore, when <acronym>IMMV</acronym> 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. +</para> + +<para> + 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. +<programlisting> +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) +</programlisting> + +</para> + +<para> + <acronym>IVM</acronym> 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, <acronym>IVM</acronym> + 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, <acronym>IVM</acronym> is not effective and the cost of + maintenance can be larger than the <command>REFRESH MATERIALIZED VIEW</command> + command. In such situation, we can use <command>REFRESH MATERIALIZED VIEW</command> + and specify <literal>WITH NO DATA</literal> to disable immediate + maintenance before modifying a base table. After a base table modification, + execute the <command>REFRESH MATERIALIZED VIEW</command> (with <literal>WITH DATA</literal>) + command to refresh the view data and enable immediate maintenance. +</para> + +</sect2> + +<sect2 id="rules-ivm-support"> +<title>Supported View Definitions and Restrictions</title> + +<para> + Currently, we can create <acronym>IMMV</acronym>s using inner joins, and some + aggregates. However, several restrictions apply to the definition of IMMV. +</para> + +<sect3 id="rules-ivm-support-joins"> +<title>Joins</title> +<para> + Inner joins including self-join are supported. Outer joins are not supported. +</para> +</sect3> + +<sect3 id="rules-ivm-support-aggregates"> +<title>Aggregates</title> +<para> + Supported aggregate functions are <function>count</function>, <function>sum</function>, + <function>avg</function>, <function>min</function>, and <function>max</function>. + 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 <acronym>IMMV</acronym>. +</para> + +<para> + Note that for <function>min</function> or <function>max</function>, 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 <acronym>IMMV</acronym> containing + these functions. +</para> + +<para> + Also note that using <function>sum</function> or <function>avg</function> on + <type>real</type> (<type>float4</type>) type or <type>double precision</type> + (<type>float8</type>) type in <acronym>IMMV</acronym> is unsafe. This is + because aggregated values in <acronym>IMMV</acronym> can become different from + results calculated from base tables due to the limited precision of these types. + To avoid this problem, use the <type>numeric</type> type instead. +</para> + + <sect4 id="rules-ivm-restrictions-aggregates"> + <title>Restrictions on Aggregates</title> + <para> + There are the following restrictions: + <itemizedlist> + <listitem> + <para> + If we have a <literal>GROUP BY</literal> clause, expressions specified in + <literal>GROUP BY</literal> must appear in the target list. This is + how tuples to be updated in the <acronym>IMMV</acronym> are identified. + These attributes are used as scan keys for searching tuples in the + <acronym>IMMV</acronym>, so indexes on them are required for efficient + <acronym>IVM</acronym>. + </para> + </listitem> + + <listitem> + <para> + <literal>HAVING</literal> clause cannot be used. + </para> + </listitem> + </itemizedlist> + </para> + </sect4> +</sect3> + +<sect3 id="rules-ivm-general-restricitons"> +<title>Other General Restrictions</title> +<para> + There are other restrictions which generally apply to <acronym>IMMV</acronym>: + <itemizedlist> + <listitem> + <para> + Sub-queries cannot be used. + </para> + </listitem> + + <listitem> + <para> + CTEs cannot be used. + </para> + </listitem> + + <listitem> + <para> + Window functions cannot be used. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s must be based on simple base tables. It's not + supported to create them on top of views, materialized views, foreign tables, inhe. + </para> + </listitem> + + <listitem> + <para> + LIMIT and OFFSET clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s cannot contain system columns. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s cannot contain non-immutable functions. + </para> + </listitem> + + <listitem> + <para> + UNION/INTERSECT/EXCEPT clauses cannnot be used. + </para> + </listitem> + + <listitem> + <para> + DISTINCT ON clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + TABLESAMPLE parameter cannot be used. + </para> + </listitem> + + <listitem> + <para> + inheritance parent tables cannnot be used. + </para> + </listitem> + + <listitem> + <para> + VALUES clause cannnot be used. + </para> + </listitem> + + <listitem> + <para> + <literal>GROUPING SETS</literal> and <literal>FILTER</literal> clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + FOR UPDATE/SHARE cannot be used. + </para> + </listitem> + + <listitem> + <para> + targetlist cannot contain columns whose name start with <literal>__ivm_</literal>. + </para> + </listitem> + + <listitem> + <para> + targetlist cannot contain expressions which contain an aggregate in it. + </para> + </listitem> + + <listitem> + <para> + Logical replication is not supported, that is, even when a base table + at a publisher node is modified, <acronym>IMMV</acronym>s at subscriber + nodes are not updated. + </para> + </listitem> + + </itemizedlist> +</para> +</sect3> + +</sect2> + +<sect2 id="rules-ivm-distinct"> +<title><literal>DISTINCT</literal></title> + +<para> + <productname>PostgreSQL</productname> supports <acronym>IMMV</acronym> with + <literal>DISTINCT</literal>. For example, suppose a <acronym>IMMV</acronym> + defined with <literal>DISTINCT</literal> 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. +</para> + +<para> + Physically, an <acronym>IMMV</acronym> defined with <literal>DISTINCT</literal> + contains tuples after eliminating duplicates, and the multiplicity of each tuple + is stored in a hidden column named <literal>__ivm_count__</literal>. +</para> +</sect2> + +<sect2 id="rules-ivm-concurrent-transactions"> +<title>Concurrent Transactions</title> +<para> + Suppose an <acronym>IMMV</acronym> is defined on two base tables and each + table was modified in different a concurrent transaction simultaneously. + In the transaction which was committed first, <acronym>IMMV</acronym> 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, <literal>ExclusiveLock</literal> + is held on an <acronym>IMMV</acronym> immediately after a base table is + modified in <literal>READ COMMITTED</literal> mode to make sure that + the <acronym>IMMV</acronym> is updated in the latter transaction after + the former transaction is committed. In <literal>REPEATABLE READ</literal> + or <literal>SERIALIZABLE</literal> 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 + <acronym>IMMV</acronym> cannot be updated correctly in such situations. + However, as an exception if the view has only one base table and + <command>INSERT</command> is performed on the table, + the lock held on thew view is <literal>RowExclusiveLock</literal>. +</para> +</sect2> + +<sect2 id="rules-ivm-rls"> +<title>Row Level Security</title> +<para> + 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. +</para> +</sect2> + +</sect1> + <sect1 id="rules-update"> <title>Rules on <command>INSERT</command>, <command>UPDATE</command>, and <command>DELETE</command></title> diff --git a/doc/src/sgml/system-views.sgml b/doc/src/sgml/system-views.sgml index 2ebec6928d5..65d1e2041d2 100644 --- a/doc/src/sgml/system-views.sgml +++ b/doc/src/sgml/system-views.sgml @@ -2231,6 +2231,15 @@ SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx </para></entry> </row> + <row> + <entry role="catalog_table_entry"><para role="column_definition"> + <structfield>isimmv</structfield> <type>bool</type> + </para> + <para> + True if materialized view is incrementally maintainable + </para></entry> + </row> + <row> <entry role="catalog_table_entry"><para role="column_definition"> <structfield>definition</structfield> <type>text</type> -- 2.43.0 --Multipart=_Fri__29_May_2026_23_14_17_+0900_Te0o73X2VqYK57Gd Content-Type: text/x-diff; name="v37-0010-Add-regression-tests-for-Incremental-View-Mainte.patch" Content-Disposition: attachment; filename="v37-0010-Add-regression-tests-for-Incremental-View-Mainte.patch" Content-Transfer-Encoding: 7bit ^ permalink raw reply [nested|flat] 22+ messages in thread
* [PATCH v38 11/11] Add documentations about Incremental View Maintenance @ 2019-12-20 01:25 Yugo Nagata <[email protected]> 0 siblings, 0 replies; 22+ messages in thread From: Yugo Nagata @ 2019-12-20 01:25 UTC (permalink / raw) --- 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 4b474c13917..9b1c88161a7 100644 --- a/doc/src/sgml/catalogs.sgml +++ b/doc/src/sgml/catalogs.sgml @@ -2276,6 +2276,15 @@ SCRAM-SHA-256$<replaceable><iteration count></replaceable>:<replaceable>&l </para></entry> </row> + <row> + <entry role="catalog_table_entry"><para role="column_definition"> + <structfield>relisivm</structfield> <type>bool</type> + </para> + <para> + True if relation is incrementally maintainable materialized view + </para></entry> + </row> + <row> <entry role="catalog_table_entry"><para role="column_definition"> <structfield>relrewrite</structfield> <type>oid</type> diff --git a/doc/src/sgml/ref/create_materialized_view.sgml b/doc/src/sgml/ref/create_materialized_view.sgml index 62d897931c3..f49db209558 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 <refsynopsisdiv> <synopsis> -CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> +CREATE [ INCREMENTAL ] MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> [ (<replaceable>column_name</replaceable> [, ...] ) ] [ USING <replaceable class="parameter">method</replaceable> ] [ WITH ( <replaceable class="parameter">storage_parameter</replaceable> [= <replaceable class="parameter">value</replaceable>] [, ... ] ) ] @@ -60,6 +60,125 @@ CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> <title>Parameters</title> <variablelist> + <varlistentry> + <term><literal>INCREMENTAL</literal></term> + <listitem> + <para> + 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). + </para> + <para> + When <acronym>IMMV</acronym> is defined without using <command>WITH NO DATA</command>, + 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. + </para> + <para> + There are restrictions of query definitions allowed to use this + option. The following are supported in query definitions for IMMV: + <itemizedlist> + + <listitem> + <para> + Inner joins (including self-joins). + </para> + </listitem> + + <listitem> + <para> + Some built-in aggregate functions (count, sum, avg, min, max) without a HAVING + clause. + </para> + </listitem> + </itemizedlist> + + Unsupported queries with this option include the following: + + <itemizedlist> + <listitem> + <para> + Outer joins. + </para> + </listitem> + + <listitem> + <para> + Sub-queries. + </para> + </listitem> + + <listitem> + <para> + Aggregate functions other than built-in count, sum, avg, min and max. + </para> + </listitem> + <listitem> + <para> + Aggregate functions with a HAVING clause. + </para> + </listitem> + <listitem> + <para> + DISTINCT ON, WINDOW, VALUES, LIMIT and OFFSET clause. + </para> + </listitem> + </itemizedlist> + + Other restrictions include: + <itemizedlist> + + <listitem> + <para> + IMMVs must be based on simple base tables. It's not supported to + create them on top of views or materialized views. + </para> + </listitem> + + <listitem> + <para> + It is not supported to include system columns in an IMMV. + <programlisting> +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 + </programlisting> + </para> + </listitem> + + <listitem> + <para> + Non-immutable functions are not supported. + <programlisting> +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 + </programlisting> + </para> + </listitem> + + <listitem> + <para> + IMMVs do not support expressions that contains aggregates + </para> + </listitem> + + <listitem> + <para> + Logical replication does not support IMMVs. + </para> + </listitem> + + </itemizedlist> + + </para> + </listitem> + </varlistentry> + <varlistentry> <term><literal>IF NOT EXISTS</literal></term> <listitem> @@ -157,7 +276,8 @@ CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> 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 <command>REFRESH - MATERIALIZED VIEW</command> is used. + MATERIALIZED VIEW</command> is used. Also, if the view is IMMV, + triggers for maintaining the view are not created. </para> </listitem> </varlistentry> diff --git a/doc/src/sgml/ref/refresh_materialized_view.sgml b/doc/src/sgml/ref/refresh_materialized_view.sgml index 8ed43ade803..a4d729bdf0f 100644 --- a/doc/src/sgml/ref/refresh_materialized_view.sgml +++ b/doc/src/sgml/ref/refresh_materialized_view.sgml @@ -36,9 +36,13 @@ REFRESH MATERIALIZED VIEW [ CONCURRENTLY ] <replaceable class="parameter">name</ privilege on the materialized view. The old contents are discarded. If <literal>WITH DATA</literal> 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 <literal>WITH NO DATA</literal> 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 <literal>WITH NO DATA</literal> 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. </para> <para> <literal>CONCURRENTLY</literal> and <literal>WITH NO DATA</literal> may not diff --git a/doc/src/sgml/rules.sgml b/doc/src/sgml/rules.sgml index 7f23962f524..da9ad3c6316 100644 --- a/doc/src/sgml/rules.sgml +++ b/doc/src/sgml/rules.sgml @@ -1103,6 +1103,443 @@ SELECT word FROM words ORDER BY word <-> 'caterpiler' LIMIT 10; </sect1> +<sect1 id="rules-ivm"> +<title>Incremental View Maintenance</title> + +<indexterm zone="rules-ivm"> + <primary>incremental view maintenance</primary> +</indexterm> + +<indexterm zone="rules-ivm"> + <primary>materialized view</primary> + <secondary>incremental view maintenance</secondary> +</indexterm> + +<indexterm zone="rules-ivm"> + <primary>view</primary> + <secondary>incremental view maintenance</secondary> +</indexterm> + +<sect2 id="rules-ivm-overview"> +<title>Overview</title> + +<para> + Incremental View Maintenance (<acronym>IVM</acronym>) 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 + <command>REFRESH MATERIALIZED VIEW</command> does. <acronym>IVM</acronym> + can update materialized views more efficiently than recomputation when only + small parts of the view are changed. +</para> + +<para> + 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 <command>REFRESH + MATERIALIZED VIEW</command>, or periodically in background, and so on. + <productname>PostgreSQL</productname> currently implements only a kind of + immediate maintenance, in which materialized views are updated immediately + in AFTER triggers when a base table is modified. +</para> + +<para> + To create materialized views supporting <acronym>IVM</acronym>, use the + <command>CREATE INCREMENTAL MATERIALIZED VIEW</command>, for example: +<programlisting> +CREATE <emphasis>INCREMENTAL</emphasis> MATERIALIZED VIEW mymatview AS SELECT * FROM mytab; +</programlisting> + When a materialized view is created with the <literal>INCREMENTAL</literal> + 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 + (<acronym>IMMV</acronym>). +<programlisting> +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) +</programlisting> +</para> + +<para> + Some <acronym>IMMV</acronym>s have hidden columns which are added + automatically when a materialized view is created. Their name starts + with <literal>__ivm_</literal> and they contain information required + for maintaining the <acronym>IMMV</acronym>. Such columns are not visible + when the <acronym>IMMV</acronym> is accessed by <literal>SELECT *</literal> + but are visible if the column name is explicitly specified in the target + list. We can also see the hidden columns in <literal>\d</literal> + meta-commands of <command>psql</command> commands. +</para> + +<para> + In general, <acronym>IMMV</acronym>s allow faster updates of materialized + views at the price of slower updates to their base tables. Updates of + <acronym>IMMV</acronym> is slower because triggers will be invoked and the + view is updated in triggers per modification statement. +</para> + +<para> + For example, suppose a normal materialized view defined as below: + +<programlisting> +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 + +</programlisting> + + Updating a tuple in a base table of this materialized view is rapid but the + <command>REFRESH MATERIALIZED VIEW</command> command on this view takes a long time: + +<programlisting> +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) +</programlisting> +</para> + +<para> + On the other hand, after creating <acronym>IMMV</acronym> with the same view + definition as below: + +<programlisting> +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" +</programlisting> + + 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 + <command>REFRESH MATERIALIZED VIEW</command> command. + +<programlisting> +test=# UPDATE pgbench_accounts SET abalance = 1000 WHERE aid = 1; +UPDATE 1 +Time: 13.068 ms +</programlisting> + +</para> + +<para> + Appropriate indexes on <acronym>IMMV</acronym>s are necessary for + efficient <acronym>IVM</acronym> because it looks for tuples to be + updated in <acronym>IMMV</acronym>. If there are no indexes, it + will take a long time. +</para> + +<para> + Therefore, when <acronym>IMMV</acronym> 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. +</para> + +<para> + 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. +<programlisting> +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) +</programlisting> + +</para> + +<para> + <acronym>IVM</acronym> 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, <acronym>IVM</acronym> + 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, <acronym>IVM</acronym> is not effective and the cost of + maintenance can be larger than the <command>REFRESH MATERIALIZED VIEW</command> + command. In such situation, we can use <command>REFRESH MATERIALIZED VIEW</command> + and specify <literal>WITH NO DATA</literal> to disable immediate + maintenance before modifying a base table. After a base table modification, + execute the <command>REFRESH MATERIALIZED VIEW</command> (with <literal>WITH DATA</literal>) + command to refresh the view data and enable immediate maintenance. +</para> + +</sect2> + +<sect2 id="rules-ivm-support"> +<title>Supported View Definitions and Restrictions</title> + +<para> + Currently, we can create <acronym>IMMV</acronym>s using inner joins, and some + aggregates. However, several restrictions apply to the definition of IMMV. +</para> + +<sect3 id="rules-ivm-support-joins"> +<title>Joins</title> +<para> + Inner joins including self-join are supported. Outer joins are not supported. +</para> +</sect3> + +<sect3 id="rules-ivm-support-aggregates"> +<title>Aggregates</title> +<para> + Supported aggregate functions are <function>count</function>, <function>sum</function>, + <function>avg</function>, <function>min</function>, and <function>max</function>. + 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 <acronym>IMMV</acronym>. +</para> + +<para> + Note that for <function>min</function> or <function>max</function>, 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 <acronym>IMMV</acronym> containing + these functions. +</para> + +<para> + Also note that using <function>sum</function> or <function>avg</function> on + <type>real</type> (<type>float4</type>) type or <type>double precision</type> + (<type>float8</type>) type in <acronym>IMMV</acronym> is unsafe. This is + because aggregated values in <acronym>IMMV</acronym> can become different from + results calculated from base tables due to the limited precision of these types. + To avoid this problem, use the <type>numeric</type> type instead. +</para> + + <sect4 id="rules-ivm-restrictions-aggregates"> + <title>Restrictions on Aggregates</title> + <para> + There are the following restrictions: + <itemizedlist> + <listitem> + <para> + If we have a <literal>GROUP BY</literal> clause, expressions specified in + <literal>GROUP BY</literal> must appear in the target list. This is + how tuples to be updated in the <acronym>IMMV</acronym> are identified. + These attributes are used as scan keys for searching tuples in the + <acronym>IMMV</acronym>, so indexes on them are required for efficient + <acronym>IVM</acronym>. + </para> + </listitem> + + <listitem> + <para> + <literal>HAVING</literal> clause cannot be used. + </para> + </listitem> + </itemizedlist> + </para> + </sect4> +</sect3> + +<sect3 id="rules-ivm-general-restricitons"> +<title>Other General Restrictions</title> +<para> + There are other restrictions which generally apply to <acronym>IMMV</acronym>: + <itemizedlist> + <listitem> + <para> + Sub-queries cannot be used. + </para> + </listitem> + + <listitem> + <para> + CTEs cannot be used. + </para> + </listitem> + + <listitem> + <para> + Window functions cannot be used. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s must be based on simple base tables. It's not + supported to create them on top of views, materialized views, foreign tables, inhe. + </para> + </listitem> + + <listitem> + <para> + LIMIT and OFFSET clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s cannot contain system columns. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s cannot contain non-immutable functions. + </para> + </listitem> + + <listitem> + <para> + UNION/INTERSECT/EXCEPT clauses cannnot be used. + </para> + </listitem> + + <listitem> + <para> + DISTINCT ON clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + TABLESAMPLE parameter cannot be used. + </para> + </listitem> + + <listitem> + <para> + inheritance parent tables cannnot be used. + </para> + </listitem> + + <listitem> + <para> + VALUES clause cannnot be used. + </para> + </listitem> + + <listitem> + <para> + <literal>GROUPING SETS</literal> and <literal>FILTER</literal> clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + FOR UPDATE/SHARE cannot be used. + </para> + </listitem> + + <listitem> + <para> + targetlist cannot contain columns whose name start with <literal>__ivm_</literal>. + </para> + </listitem> + + <listitem> + <para> + targetlist cannot contain expressions which contain an aggregate in it. + </para> + </listitem> + + <listitem> + <para> + Logical replication is not supported, that is, even when a base table + at a publisher node is modified, <acronym>IMMV</acronym>s at subscriber + nodes are not updated. + </para> + </listitem> + + </itemizedlist> +</para> +</sect3> + +</sect2> + +<sect2 id="rules-ivm-distinct"> +<title><literal>DISTINCT</literal></title> + +<para> + <productname>PostgreSQL</productname> supports <acronym>IMMV</acronym> with + <literal>DISTINCT</literal>. For example, suppose a <acronym>IMMV</acronym> + defined with <literal>DISTINCT</literal> 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. +</para> + +<para> + Physically, an <acronym>IMMV</acronym> defined with <literal>DISTINCT</literal> + contains tuples after eliminating duplicates, and the multiplicity of each tuple + is stored in a hidden column named <literal>__ivm_count__</literal>. +</para> +</sect2> + +<sect2 id="rules-ivm-concurrent-transactions"> +<title>Concurrent Transactions</title> +<para> + Suppose an <acronym>IMMV</acronym> is defined on two base tables and each + table was modified in different a concurrent transaction simultaneously. + In the transaction which was committed first, <acronym>IMMV</acronym> 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, <literal>ExclusiveLock</literal> + is held on an <acronym>IMMV</acronym> immediately after a base table is + modified in <literal>READ COMMITTED</literal> mode to make sure that + the <acronym>IMMV</acronym> is updated in the latter transaction after + the former transaction is committed. In <literal>REPEATABLE READ</literal> + or <literal>SERIALIZABLE</literal> 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 + <acronym>IMMV</acronym> cannot be updated correctly in such situations. + However, as an exception if the view has only one base table and + <command>INSERT</command> is performed on the table, + the lock held on thew view is <literal>RowExclusiveLock</literal>. +</para> +</sect2> + +<sect2 id="rules-ivm-rls"> +<title>Row Level Security</title> +<para> + 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. +</para> +</sect2> + +</sect1> + <sect1 id="rules-update"> <title>Rules on <command>INSERT</command>, <command>UPDATE</command>, and <command>DELETE</command></title> diff --git a/doc/src/sgml/system-views.sgml b/doc/src/sgml/system-views.sgml index 2ebec6928d5..65d1e2041d2 100644 --- a/doc/src/sgml/system-views.sgml +++ b/doc/src/sgml/system-views.sgml @@ -2231,6 +2231,15 @@ SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx </para></entry> </row> + <row> + <entry role="catalog_table_entry"><para role="column_definition"> + <structfield>isimmv</structfield> <type>bool</type> + </para> + <para> + True if materialized view is incrementally maintainable + </para></entry> + </row> + <row> <entry role="catalog_table_entry"><para role="column_definition"> <structfield>definition</structfield> <type>text</type> -- 2.43.0 --Multipart=_Wed__1_Jul_2026_00_04_01_+0900_OVSy2WWK_9aByzDJ Content-Type: text/x-diff; name="v38-0010-Add-regression-tests-for-Incremental-View-Mainte.patch" Content-Disposition: attachment; filename="v38-0010-Add-regression-tests-for-Incremental-View-Mainte.patch" Content-Transfer-Encoding: 7bit ^ permalink raw reply [nested|flat] 22+ messages in thread
* [PATCH v29 11/11] Add documentations about Incremental View Maintenance @ 2019-12-20 01:25 Yugo Nagata <[email protected]> 0 siblings, 0 replies; 22+ messages in thread From: Yugo Nagata @ 2019-12-20 01:25 UTC (permalink / raw) --- 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$<replaceable><iteration count></replaceable>:<replaceable>&l </para></entry> </row> + <row> + <entry role="catalog_table_entry"><para role="column_definition"> + <structfield>relisivm</structfield> <type>bool</type> + </para> + <para> + True if relation is incrementally maintainable materialized view + </para></entry> + </row> + <row> <entry role="catalog_table_entry"><para role="column_definition"> <structfield>relrewrite</structfield> <type>oid</type> 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 <refsynopsisdiv> <synopsis> -CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> +CREATE [ INCREMENTAL ] MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> [ (<replaceable>column_name</replaceable> [, ...] ) ] [ USING <replaceable class="parameter">method</replaceable> ] [ WITH ( <replaceable class="parameter">storage_parameter</replaceable> [= <replaceable class="parameter">value</replaceable>] [, ... ] ) ] @@ -60,6 +60,125 @@ CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> <title>Parameters</title> <variablelist> + <varlistentry> + <term><literal>INCREMENTAL</literal></term> + <listitem> + <para> + 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). + </para> + <para> + When <acronym>IMMV</acronym> is defined without using <command>WITH NO DATA</command>, + 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. + </para> + <para> + There are restrictions of query definitions allowed to use this + option. The following are supported in query definitions for IMMV: + <itemizedlist> + + <listitem> + <para> + Inner joins (including self-joins). + </para> + </listitem> + + <listitem> + <para> + Some built-in aggregate functions (count, sum, avg, min, max) without a HAVING + clause. + </para> + </listitem> + </itemizedlist> + + Unsupported queries with this option include the following: + + <itemizedlist> + <listitem> + <para> + Outer joins. + </para> + </listitem> + + <listitem> + <para> + Sub-queries. + </para> + </listitem> + + <listitem> + <para> + Aggregate functions other than built-in count, sum, avg, min and max. + </para> + </listitem> + <listitem> + <para> + Aggregate functions with a HAVING clause. + </para> + </listitem> + <listitem> + <para> + DISTINCT ON, WINDOW, VALUES, LIMIT and OFFSET clause. + </para> + </listitem> + </itemizedlist> + + Other restrictions include: + <itemizedlist> + + <listitem> + <para> + IMMVs must be based on simple base tables. It's not supported to + create them on top of views or materialized views. + </para> + </listitem> + + <listitem> + <para> + It is not supported to include system columns in an IMMV. + <programlisting> +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 + </programlisting> + </para> + </listitem> + + <listitem> + <para> + Non-immutable functions are not supported. + <programlisting> +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 + </programlisting> + </para> + </listitem> + + <listitem> + <para> + IMMVs do not support expressions that contains aggregates + </para> + </listitem> + + <listitem> + <para> + Logical replication does not support IMMVs. + </para> + </listitem> + + </itemizedlist> + + </para> + </listitem> + </varlistentry> + <varlistentry> <term><literal>IF NOT EXISTS</literal></term> <listitem> @@ -155,7 +274,8 @@ CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> 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 <command>REFRESH - MATERIALIZED VIEW</command> is used. + MATERIALIZED VIEW</command> is used. Also, if the view is IMMV, + triggers for maintaining the view are not created. </para> </listitem> </varlistentry> 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 ] <replaceable class="parameter">name</ owner of the materialized view. The old contents are discarded. If <literal>WITH DATA</literal> 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 <literal>WITH NO DATA</literal> 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 <literal>WITH NO DATA</literal> 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. </para> <para> <literal>CONCURRENTLY</literal> and <literal>WITH NO DATA</literal> 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; </sect1> +<sect1 id="rules-ivm"> +<title>Incremental View Maintenance</title> + +<indexterm zone="rules-ivm"> + <primary>incremental view maintenance</primary> +</indexterm> + +<indexterm zone="rules-ivm"> + <primary>materialized view</primary> + <secondary>incremental view maintenance</secondary> +</indexterm> + +<indexterm zone="rules-ivm"> + <primary>view</primary> + <secondary>incremental view maintenance</secondary> +</indexterm> + +<sect2 id="rules-ivm-overview"> +<title>Overview</title> + +<para> + Incremental View Maintenance (<acronym>IVM</acronym>) 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 + <command>REFRESH MATERIALIZED VIEW</command> does. <acronym>IVM</acronym> + can update materialized views more efficiently than recomputation when only + small parts of the view are changed. +</para> + +<para> + 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 <command>REFRESH + MATERIALIZED VIEW</command>, or periodically in background, and so on. + <productname>PostgreSQL</productname> currently implements only a kind of + immediate maintenance, in which materialized views are updated immediately + in AFTER triggers when a base table is modified. +</para> + +<para> + To create materialized views supporting <acronym>IVM</acronym>, use the + <command>CREATE INCREMENTAL MATERIALIZED VIEW</command>, for example: +<programlisting> +CREATE <emphasis>INCREMENTAL</emphasis> MATERIALIZED VIEW mymatview AS SELECT * FROM mytab; +</programlisting> + When a materialized view is created with the <literal>INCREMENTAL</literal> + 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 + (<acronym>IMMV</acronym>). +<programlisting> +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) +</programlisting> +</para> + +<para> + Some <acronym>IMMV</acronym>s have hidden columns which are added + automatically when a materialized view is created. Their name starts + with <literal>__ivm_</literal> and they contain information required + for maintaining the <acronym>IMMV</acronym>. Such columns are not visible + when the <acronym>IMMV</acronym> is accessed by <literal>SELECT *</literal> + but are visible if the column name is explicitly specified in the target + list. We can also see the hidden columns in <literal>\d</literal> + meta-commands of <command>psql</command> commands. +</para> + +<para> + In general, <acronym>IMMV</acronym>s allow faster updates of materialized + views at the price of slower updates to their base tables. Updates of + <acronym>IMMV</acronym> is slower because triggers will be invoked and the + view is updated in triggers per modification statement. +</para> + +<para> + For example, suppose a normal materialized view defined as below: + +<programlisting> +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 + +</programlisting> + + Updating a tuple in a base table of this materialized view is rapid but the + <command>REFRESH MATERIALIZED VIEW</command> command on this view takes a long time: + +<programlisting> +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) +</programlisting> +</para> + +<para> + On the other hand, after creating <acronym>IMMV</acronym> with the same view + definition as below: + +<programlisting> +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" +</programlisting> + + 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 + <command>REFRESH MATERIALIZED VIEW</command> command. + +<programlisting> +test=# UPDATE pgbench_accounts SET abalance = 1000 WHERE aid = 1; +UPDATE 1 +Time: 13.068 ms +</programlisting> + +</para> + +<para> + Appropriate indexes on <acronym>IMMV</acronym>s are necessary for + efficient <acronym>IVM</acronym> because it looks for tuples to be + updated in <acronym>IMMV</acronym>. If there are no indexes, it + will take a long time. +</para> + +<para> + Therefore, when <acronym>IMMV</acronym> 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. +</para> + +<para> + 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. +<programlisting> +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) +</programlisting> + +</para> + +<para> + <acronym>IVM</acronym> 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, <acronym>IVM</acronym> + 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, <acronym>IVM</acronym> is not effective and the cost of + maintenance can be larger than the <command>REFRESH MATERIALIZED VIEW</command> + command. In such situation, we can use <command>REFRESH MATERIALIZED VIEW</command> + and specify <literal>WITH NO DATA</literal> to disable immediate + maintenance before modifying a base table. After a base table modification, + execute the <command>REFRESH MATERIALIZED VIEW</command> (with <literal>WITH DATA</literal>) + command to refresh the view data and enable immediate maintenance. +</para> + +</sect2> + +<sect2 id="rules-ivm-support"> +<title>Supported View Definitions and Restrictions</title> + +<para> + Currently, we can create <acronym>IMMV</acronym>s using inner joins, and some + aggregates. However, several restrictions apply to the definition of IMMV. +</para> + +<sect3 id="rules-ivm-support-joins"> +<title>Joins</title> +<para> + Inner joins including self-join are supported. Outer joins are not supported. +</para> +</sect3> + +<sect3 id="rules-ivm-support-aggregates"> +<title>Aggregates</title> +<para> + Supported aggregate functions are <function>count</function>, <function>sum</function>, + <function>avg</function>, <function>min</function>, and <function>max</function>. + 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 <acronym>IMMV</acronym>. +</para> + +<para> + Note that for <function>min</function> or <function>max</function>, 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 <acronym>IMMV</acronym> containing + these functions. +</para> + +<para> + Also note that using <function>sum</function> or <function>avg</function> on + <type>real</type> (<type>float4</type>) type or <type>double precision</type> + (<type>float8</type>) type in <acronym>IMMV</acronym> is unsafe. This is + because aggregated values in <acronym>IMMV</acronym> can become different from + results calculated from base tables due to the limited precision of these types. + To avoid this problem, use the <type>numeric</type> type instead. +</para> + + <sect4 id="rules-ivm-restrictions-aggregates"> + <title>Restrictions on Aggregates</title> + <para> + There are the following restrictions: + <itemizedlist> + <listitem> + <para> + If we have a <literal>GROUP BY</literal> clause, expressions specified in + <literal>GROUP BY</literal> must appear in the target list. This is + how tuples to be updated in the <acronym>IMMV</acronym> are identified. + These attributes are used as scan keys for searching tuples in the + <acronym>IMMV</acronym>, so indexes on them are required for efficient + <acronym>IVM</acronym>. + </para> + </listitem> + + <listitem> + <para> + <literal>HAVING</literal> clause cannot be used. + </para> + </listitem> + </itemizedlist> + </para> + </sect4> +</sect3> + +<sect3 id="rules-ivm-general-restricitons"> +<title>Other General Restrictions</title> +<para> + There are other restrictions which generally apply to <acronym>IMMV</acronym>: + <itemizedlist> + <listitem> + <para> + Sub-queries cannot be used. + </para> + </listitem> + + <listitem> + <para> + CTEs cannot be used. + </para> + </listitem> + + <listitem> + <para> + Window functions cannot be used. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s must be based on simple base tables. It's not + supported to create them on top of views, materialized views, foreign tables, inhe. + </para> + </listitem> + + <listitem> + <para> + LIMIT and OFFSET clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s cannot contain system columns. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s cannot contain non-immutable functions. + </para> + </listitem> + + <listitem> + <para> + UNION/INTERSECT/EXCEPT clauses cannnot be used. + </para> + </listitem> + + <listitem> + <para> + DISTINCT ON clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + TABLESAMPLE parameter cannot be used. + </para> + </listitem> + + <listitem> + <para> + inheritance parent tables cannnot be used. + </para> + </listitem> + + <listitem> + <para> + VALUES clause cannnot be used. + </para> + </listitem> + + <listitem> + <para> + <literal>GROUPING SETS</literal> and <literal>FILTER</literal> clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + FOR UPDATE/SHARE cannot be used. + </para> + </listitem> + + <listitem> + <para> + targetlist cannot contain columns whose name start with <literal>__ivm_</literal>. + </para> + </listitem> + + <listitem> + <para> + targetlist cannot contain expressions which contain an aggregate in it. + </para> + </listitem> + + <listitem> + <para> + Logical replication is not supported, that is, even when a base table + at a publisher node is modified, <acronym>IMMV</acronym>s at subscriber + nodes are not updated. + </para> + </listitem> + + </itemizedlist> +</para> +</sect3> + +</sect2> + +<sect2 id="rules-ivm-distinct"> +<title><literal>DISTINCT</literal></title> + +<para> + <productname>PostgreSQL</productname> supports <acronym>IMMV</acronym> with + <literal>DISTINCT</literal>. For example, suppose a <acronym>IMMV</acronym> + defined with <literal>DISTINCT</literal> 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. +</para> + +<para> + Physically, an <acronym>IMMV</acronym> defined with <literal>DISTINCT</literal> + contains tuples after eliminating duplicates, and the multiplicity of each tuple + is stored in a hidden column named <literal>__ivm_count__</literal>. +</para> +</sect2> + +<sect2 id="rules-ivm-concurrent-transactions"> +<title>Concurrent Transactions</title> +<para> + Suppose an <acronym>IMMV</acronym> is defined on two base tables and each + table was modified in different a concurrent transaction simultaneously. + In the transaction which was committed first, <acronym>IMMV</acronym> 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, <literal>ExclusiveLock</literal> + is held on an <acronym>IMMV</acronym> immediately after a base table is + modified in <literal>READ COMMITTED</literal> mode to make sure that + the <acronym>IMMV</acronym> is updated in the latter transaction after + the former transaction is committed. In <literal>REPEATABLE READ</literal> + or <literal>SERIALIZABLE</literal> 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 + <acronym>IMMV</acronym> cannot be updated correctly in such situations. + However, as an exception if the view has only one base table and + <command>INSERT</command> is performed on the table, + the lock held on thew view is <literal>RowExclusiveLock</literal>. +</para> +</sect2> + +<sect2 id="rules-ivm-rls"> +<title>Row Level Security</title> +<para> + 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. +</para> +</sect2> + +</sect1> + <sect1 id="rules-update"> <title>Rules on <command>INSERT</command>, <command>UPDATE</command>, and <command>DELETE</command></title> 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 </para></entry> </row> + <row> + <entry role="catalog_table_entry"><para role="column_definition"> + <structfield>isimmv</structfield> <type>bool</type> + </para> + <para> + True if materialized view is incrementally maintainable + </para></entry> + </row> + <row> <entry role="catalog_table_entry"><para role="column_definition"> <structfield>definition</structfield> <type>text</type> -- 2.25.1 --Multipart=_Mon__28_Aug_2023_11_52_52_+0900_hj6L5h176QaSGtg7-- ^ permalink raw reply [nested|flat] 22+ messages in thread
* [PATCH v29 11/11] Add documentations about Incremental View Maintenance @ 2019-12-20 01:25 Yugo Nagata <[email protected]> 0 siblings, 0 replies; 22+ messages in thread From: Yugo Nagata @ 2019-12-20 01:25 UTC (permalink / raw) --- 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$<replaceable><iteration count></replaceable>:<replaceable>&l </para></entry> </row> + <row> + <entry role="catalog_table_entry"><para role="column_definition"> + <structfield>relisivm</structfield> <type>bool</type> + </para> + <para> + True if relation is incrementally maintainable materialized view + </para></entry> + </row> + <row> <entry role="catalog_table_entry"><para role="column_definition"> <structfield>relrewrite</structfield> <type>oid</type> 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 <refsynopsisdiv> <synopsis> -CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> +CREATE [ INCREMENTAL ] MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> [ (<replaceable>column_name</replaceable> [, ...] ) ] [ USING <replaceable class="parameter">method</replaceable> ] [ WITH ( <replaceable class="parameter">storage_parameter</replaceable> [= <replaceable class="parameter">value</replaceable>] [, ... ] ) ] @@ -60,6 +60,125 @@ CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> <title>Parameters</title> <variablelist> + <varlistentry> + <term><literal>INCREMENTAL</literal></term> + <listitem> + <para> + 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). + </para> + <para> + When <acronym>IMMV</acronym> is defined without using <command>WITH NO DATA</command>, + 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. + </para> + <para> + There are restrictions of query definitions allowed to use this + option. The following are supported in query definitions for IMMV: + <itemizedlist> + + <listitem> + <para> + Inner joins (including self-joins). + </para> + </listitem> + + <listitem> + <para> + Some built-in aggregate functions (count, sum, avg, min, max) without a HAVING + clause. + </para> + </listitem> + </itemizedlist> + + Unsupported queries with this option include the following: + + <itemizedlist> + <listitem> + <para> + Outer joins. + </para> + </listitem> + + <listitem> + <para> + Sub-queries. + </para> + </listitem> + + <listitem> + <para> + Aggregate functions other than built-in count, sum, avg, min and max. + </para> + </listitem> + <listitem> + <para> + Aggregate functions with a HAVING clause. + </para> + </listitem> + <listitem> + <para> + DISTINCT ON, WINDOW, VALUES, LIMIT and OFFSET clause. + </para> + </listitem> + </itemizedlist> + + Other restrictions include: + <itemizedlist> + + <listitem> + <para> + IMMVs must be based on simple base tables. It's not supported to + create them on top of views or materialized views. + </para> + </listitem> + + <listitem> + <para> + It is not supported to include system columns in an IMMV. + <programlisting> +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 + </programlisting> + </para> + </listitem> + + <listitem> + <para> + Non-immutable functions are not supported. + <programlisting> +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 + </programlisting> + </para> + </listitem> + + <listitem> + <para> + IMMVs do not support expressions that contains aggregates + </para> + </listitem> + + <listitem> + <para> + Logical replication does not support IMMVs. + </para> + </listitem> + + </itemizedlist> + + </para> + </listitem> + </varlistentry> + <varlistentry> <term><literal>IF NOT EXISTS</literal></term> <listitem> @@ -155,7 +274,8 @@ CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> 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 <command>REFRESH - MATERIALIZED VIEW</command> is used. + MATERIALIZED VIEW</command> is used. Also, if the view is IMMV, + triggers for maintaining the view are not created. </para> </listitem> </varlistentry> 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 ] <replaceable class="parameter">name</ owner of the materialized view. The old contents are discarded. If <literal>WITH DATA</literal> 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 <literal>WITH NO DATA</literal> 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 <literal>WITH NO DATA</literal> 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. </para> <para> <literal>CONCURRENTLY</literal> and <literal>WITH NO DATA</literal> 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; </sect1> +<sect1 id="rules-ivm"> +<title>Incremental View Maintenance</title> + +<indexterm zone="rules-ivm"> + <primary>incremental view maintenance</primary> +</indexterm> + +<indexterm zone="rules-ivm"> + <primary>materialized view</primary> + <secondary>incremental view maintenance</secondary> +</indexterm> + +<indexterm zone="rules-ivm"> + <primary>view</primary> + <secondary>incremental view maintenance</secondary> +</indexterm> + +<sect2 id="rules-ivm-overview"> +<title>Overview</title> + +<para> + Incremental View Maintenance (<acronym>IVM</acronym>) 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 + <command>REFRESH MATERIALIZED VIEW</command> does. <acronym>IVM</acronym> + can update materialized views more efficiently than recomputation when only + small parts of the view are changed. +</para> + +<para> + 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 <command>REFRESH + MATERIALIZED VIEW</command>, or periodically in background, and so on. + <productname>PostgreSQL</productname> currently implements only a kind of + immediate maintenance, in which materialized views are updated immediately + in AFTER triggers when a base table is modified. +</para> + +<para> + To create materialized views supporting <acronym>IVM</acronym>, use the + <command>CREATE INCREMENTAL MATERIALIZED VIEW</command>, for example: +<programlisting> +CREATE <emphasis>INCREMENTAL</emphasis> MATERIALIZED VIEW mymatview AS SELECT * FROM mytab; +</programlisting> + When a materialized view is created with the <literal>INCREMENTAL</literal> + 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 + (<acronym>IMMV</acronym>). +<programlisting> +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) +</programlisting> +</para> + +<para> + Some <acronym>IMMV</acronym>s have hidden columns which are added + automatically when a materialized view is created. Their name starts + with <literal>__ivm_</literal> and they contain information required + for maintaining the <acronym>IMMV</acronym>. Such columns are not visible + when the <acronym>IMMV</acronym> is accessed by <literal>SELECT *</literal> + but are visible if the column name is explicitly specified in the target + list. We can also see the hidden columns in <literal>\d</literal> + meta-commands of <command>psql</command> commands. +</para> + +<para> + In general, <acronym>IMMV</acronym>s allow faster updates of materialized + views at the price of slower updates to their base tables. Updates of + <acronym>IMMV</acronym> is slower because triggers will be invoked and the + view is updated in triggers per modification statement. +</para> + +<para> + For example, suppose a normal materialized view defined as below: + +<programlisting> +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 + +</programlisting> + + Updating a tuple in a base table of this materialized view is rapid but the + <command>REFRESH MATERIALIZED VIEW</command> command on this view takes a long time: + +<programlisting> +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) +</programlisting> +</para> + +<para> + On the other hand, after creating <acronym>IMMV</acronym> with the same view + definition as below: + +<programlisting> +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" +</programlisting> + + 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 + <command>REFRESH MATERIALIZED VIEW</command> command. + +<programlisting> +test=# UPDATE pgbench_accounts SET abalance = 1000 WHERE aid = 1; +UPDATE 1 +Time: 13.068 ms +</programlisting> + +</para> + +<para> + Appropriate indexes on <acronym>IMMV</acronym>s are necessary for + efficient <acronym>IVM</acronym> because it looks for tuples to be + updated in <acronym>IMMV</acronym>. If there are no indexes, it + will take a long time. +</para> + +<para> + Therefore, when <acronym>IMMV</acronym> 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. +</para> + +<para> + 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. +<programlisting> +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) +</programlisting> + +</para> + +<para> + <acronym>IVM</acronym> 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, <acronym>IVM</acronym> + 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, <acronym>IVM</acronym> is not effective and the cost of + maintenance can be larger than the <command>REFRESH MATERIALIZED VIEW</command> + command. In such situation, we can use <command>REFRESH MATERIALIZED VIEW</command> + and specify <literal>WITH NO DATA</literal> to disable immediate + maintenance before modifying a base table. After a base table modification, + execute the <command>REFRESH MATERIALIZED VIEW</command> (with <literal>WITH DATA</literal>) + command to refresh the view data and enable immediate maintenance. +</para> + +</sect2> + +<sect2 id="rules-ivm-support"> +<title>Supported View Definitions and Restrictions</title> + +<para> + Currently, we can create <acronym>IMMV</acronym>s using inner joins, and some + aggregates. However, several restrictions apply to the definition of IMMV. +</para> + +<sect3 id="rules-ivm-support-joins"> +<title>Joins</title> +<para> + Inner joins including self-join are supported. Outer joins are not supported. +</para> +</sect3> + +<sect3 id="rules-ivm-support-aggregates"> +<title>Aggregates</title> +<para> + Supported aggregate functions are <function>count</function>, <function>sum</function>, + <function>avg</function>, <function>min</function>, and <function>max</function>. + 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 <acronym>IMMV</acronym>. +</para> + +<para> + Note that for <function>min</function> or <function>max</function>, 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 <acronym>IMMV</acronym> containing + these functions. +</para> + +<para> + Also note that using <function>sum</function> or <function>avg</function> on + <type>real</type> (<type>float4</type>) type or <type>double precision</type> + (<type>float8</type>) type in <acronym>IMMV</acronym> is unsafe. This is + because aggregated values in <acronym>IMMV</acronym> can become different from + results calculated from base tables due to the limited precision of these types. + To avoid this problem, use the <type>numeric</type> type instead. +</para> + + <sect4 id="rules-ivm-restrictions-aggregates"> + <title>Restrictions on Aggregates</title> + <para> + There are the following restrictions: + <itemizedlist> + <listitem> + <para> + If we have a <literal>GROUP BY</literal> clause, expressions specified in + <literal>GROUP BY</literal> must appear in the target list. This is + how tuples to be updated in the <acronym>IMMV</acronym> are identified. + These attributes are used as scan keys for searching tuples in the + <acronym>IMMV</acronym>, so indexes on them are required for efficient + <acronym>IVM</acronym>. + </para> + </listitem> + + <listitem> + <para> + <literal>HAVING</literal> clause cannot be used. + </para> + </listitem> + </itemizedlist> + </para> + </sect4> +</sect3> + +<sect3 id="rules-ivm-general-restricitons"> +<title>Other General Restrictions</title> +<para> + There are other restrictions which generally apply to <acronym>IMMV</acronym>: + <itemizedlist> + <listitem> + <para> + Sub-queries cannot be used. + </para> + </listitem> + + <listitem> + <para> + CTEs cannot be used. + </para> + </listitem> + + <listitem> + <para> + Window functions cannot be used. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s must be based on simple base tables. It's not + supported to create them on top of views, materialized views, foreign tables, inhe. + </para> + </listitem> + + <listitem> + <para> + LIMIT and OFFSET clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s cannot contain system columns. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s cannot contain non-immutable functions. + </para> + </listitem> + + <listitem> + <para> + UNION/INTERSECT/EXCEPT clauses cannnot be used. + </para> + </listitem> + + <listitem> + <para> + DISTINCT ON clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + TABLESAMPLE parameter cannot be used. + </para> + </listitem> + + <listitem> + <para> + inheritance parent tables cannnot be used. + </para> + </listitem> + + <listitem> + <para> + VALUES clause cannnot be used. + </para> + </listitem> + + <listitem> + <para> + <literal>GROUPING SETS</literal> and <literal>FILTER</literal> clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + FOR UPDATE/SHARE cannot be used. + </para> + </listitem> + + <listitem> + <para> + targetlist cannot contain columns whose name start with <literal>__ivm_</literal>. + </para> + </listitem> + + <listitem> + <para> + targetlist cannot contain expressions which contain an aggregate in it. + </para> + </listitem> + + <listitem> + <para> + Logical replication is not supported, that is, even when a base table + at a publisher node is modified, <acronym>IMMV</acronym>s at subscriber + nodes are not updated. + </para> + </listitem> + + </itemizedlist> +</para> +</sect3> + +</sect2> + +<sect2 id="rules-ivm-distinct"> +<title><literal>DISTINCT</literal></title> + +<para> + <productname>PostgreSQL</productname> supports <acronym>IMMV</acronym> with + <literal>DISTINCT</literal>. For example, suppose a <acronym>IMMV</acronym> + defined with <literal>DISTINCT</literal> 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. +</para> + +<para> + Physically, an <acronym>IMMV</acronym> defined with <literal>DISTINCT</literal> + contains tuples after eliminating duplicates, and the multiplicity of each tuple + is stored in a hidden column named <literal>__ivm_count__</literal>. +</para> +</sect2> + +<sect2 id="rules-ivm-concurrent-transactions"> +<title>Concurrent Transactions</title> +<para> + Suppose an <acronym>IMMV</acronym> is defined on two base tables and each + table was modified in different a concurrent transaction simultaneously. + In the transaction which was committed first, <acronym>IMMV</acronym> 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, <literal>ExclusiveLock</literal> + is held on an <acronym>IMMV</acronym> immediately after a base table is + modified in <literal>READ COMMITTED</literal> mode to make sure that + the <acronym>IMMV</acronym> is updated in the latter transaction after + the former transaction is committed. In <literal>REPEATABLE READ</literal> + or <literal>SERIALIZABLE</literal> 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 + <acronym>IMMV</acronym> cannot be updated correctly in such situations. + However, as an exception if the view has only one base table and + <command>INSERT</command> is performed on the table, + the lock held on thew view is <literal>RowExclusiveLock</literal>. +</para> +</sect2> + +<sect2 id="rules-ivm-rls"> +<title>Row Level Security</title> +<para> + 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. +</para> +</sect2> + +</sect1> + <sect1 id="rules-update"> <title>Rules on <command>INSERT</command>, <command>UPDATE</command>, and <command>DELETE</command></title> 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 </para></entry> </row> + <row> + <entry role="catalog_table_entry"><para role="column_definition"> + <structfield>isimmv</structfield> <type>bool</type> + </para> + <para> + True if materialized view is incrementally maintainable + </para></entry> + </row> + <row> <entry role="catalog_table_entry"><para role="column_definition"> <structfield>definition</structfield> <type>text</type> -- 2.25.1 --Multipart=_Mon__28_Aug_2023_16_05_30_+0900_b1OvQD_3A3ZMTGvj-- ^ permalink raw reply [nested|flat] 22+ messages in thread
* [PATCH v37 11/11] Add documentations about Incremental View Maintenance @ 2019-12-20 01:25 Yugo Nagata <[email protected]> 0 siblings, 0 replies; 22+ messages in thread From: Yugo Nagata @ 2019-12-20 01:25 UTC (permalink / raw) --- 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 4b474c13917..9b1c88161a7 100644 --- a/doc/src/sgml/catalogs.sgml +++ b/doc/src/sgml/catalogs.sgml @@ -2276,6 +2276,15 @@ SCRAM-SHA-256$<replaceable><iteration count></replaceable>:<replaceable>&l </para></entry> </row> + <row> + <entry role="catalog_table_entry"><para role="column_definition"> + <structfield>relisivm</structfield> <type>bool</type> + </para> + <para> + True if relation is incrementally maintainable materialized view + </para></entry> + </row> + <row> <entry role="catalog_table_entry"><para role="column_definition"> <structfield>relrewrite</structfield> <type>oid</type> diff --git a/doc/src/sgml/ref/create_materialized_view.sgml b/doc/src/sgml/ref/create_materialized_view.sgml index 62d897931c3..f49db209558 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 <refsynopsisdiv> <synopsis> -CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> +CREATE [ INCREMENTAL ] MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> [ (<replaceable>column_name</replaceable> [, ...] ) ] [ USING <replaceable class="parameter">method</replaceable> ] [ WITH ( <replaceable class="parameter">storage_parameter</replaceable> [= <replaceable class="parameter">value</replaceable>] [, ... ] ) ] @@ -60,6 +60,125 @@ CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> <title>Parameters</title> <variablelist> + <varlistentry> + <term><literal>INCREMENTAL</literal></term> + <listitem> + <para> + 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). + </para> + <para> + When <acronym>IMMV</acronym> is defined without using <command>WITH NO DATA</command>, + 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. + </para> + <para> + There are restrictions of query definitions allowed to use this + option. The following are supported in query definitions for IMMV: + <itemizedlist> + + <listitem> + <para> + Inner joins (including self-joins). + </para> + </listitem> + + <listitem> + <para> + Some built-in aggregate functions (count, sum, avg, min, max) without a HAVING + clause. + </para> + </listitem> + </itemizedlist> + + Unsupported queries with this option include the following: + + <itemizedlist> + <listitem> + <para> + Outer joins. + </para> + </listitem> + + <listitem> + <para> + Sub-queries. + </para> + </listitem> + + <listitem> + <para> + Aggregate functions other than built-in count, sum, avg, min and max. + </para> + </listitem> + <listitem> + <para> + Aggregate functions with a HAVING clause. + </para> + </listitem> + <listitem> + <para> + DISTINCT ON, WINDOW, VALUES, LIMIT and OFFSET clause. + </para> + </listitem> + </itemizedlist> + + Other restrictions include: + <itemizedlist> + + <listitem> + <para> + IMMVs must be based on simple base tables. It's not supported to + create them on top of views or materialized views. + </para> + </listitem> + + <listitem> + <para> + It is not supported to include system columns in an IMMV. + <programlisting> +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 + </programlisting> + </para> + </listitem> + + <listitem> + <para> + Non-immutable functions are not supported. + <programlisting> +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 + </programlisting> + </para> + </listitem> + + <listitem> + <para> + IMMVs do not support expressions that contains aggregates + </para> + </listitem> + + <listitem> + <para> + Logical replication does not support IMMVs. + </para> + </listitem> + + </itemizedlist> + + </para> + </listitem> + </varlistentry> + <varlistentry> <term><literal>IF NOT EXISTS</literal></term> <listitem> @@ -157,7 +276,8 @@ CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> 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 <command>REFRESH - MATERIALIZED VIEW</command> is used. + MATERIALIZED VIEW</command> is used. Also, if the view is IMMV, + triggers for maintaining the view are not created. </para> </listitem> </varlistentry> diff --git a/doc/src/sgml/ref/refresh_materialized_view.sgml b/doc/src/sgml/ref/refresh_materialized_view.sgml index 8ed43ade803..a4d729bdf0f 100644 --- a/doc/src/sgml/ref/refresh_materialized_view.sgml +++ b/doc/src/sgml/ref/refresh_materialized_view.sgml @@ -36,9 +36,13 @@ REFRESH MATERIALIZED VIEW [ CONCURRENTLY ] <replaceable class="parameter">name</ privilege on the materialized view. The old contents are discarded. If <literal>WITH DATA</literal> 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 <literal>WITH NO DATA</literal> 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 <literal>WITH NO DATA</literal> 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. </para> <para> <literal>CONCURRENTLY</literal> and <literal>WITH NO DATA</literal> may not diff --git a/doc/src/sgml/rules.sgml b/doc/src/sgml/rules.sgml index 7f23962f524..da9ad3c6316 100644 --- a/doc/src/sgml/rules.sgml +++ b/doc/src/sgml/rules.sgml @@ -1103,6 +1103,443 @@ SELECT word FROM words ORDER BY word <-> 'caterpiler' LIMIT 10; </sect1> +<sect1 id="rules-ivm"> +<title>Incremental View Maintenance</title> + +<indexterm zone="rules-ivm"> + <primary>incremental view maintenance</primary> +</indexterm> + +<indexterm zone="rules-ivm"> + <primary>materialized view</primary> + <secondary>incremental view maintenance</secondary> +</indexterm> + +<indexterm zone="rules-ivm"> + <primary>view</primary> + <secondary>incremental view maintenance</secondary> +</indexterm> + +<sect2 id="rules-ivm-overview"> +<title>Overview</title> + +<para> + Incremental View Maintenance (<acronym>IVM</acronym>) 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 + <command>REFRESH MATERIALIZED VIEW</command> does. <acronym>IVM</acronym> + can update materialized views more efficiently than recomputation when only + small parts of the view are changed. +</para> + +<para> + 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 <command>REFRESH + MATERIALIZED VIEW</command>, or periodically in background, and so on. + <productname>PostgreSQL</productname> currently implements only a kind of + immediate maintenance, in which materialized views are updated immediately + in AFTER triggers when a base table is modified. +</para> + +<para> + To create materialized views supporting <acronym>IVM</acronym>, use the + <command>CREATE INCREMENTAL MATERIALIZED VIEW</command>, for example: +<programlisting> +CREATE <emphasis>INCREMENTAL</emphasis> MATERIALIZED VIEW mymatview AS SELECT * FROM mytab; +</programlisting> + When a materialized view is created with the <literal>INCREMENTAL</literal> + 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 + (<acronym>IMMV</acronym>). +<programlisting> +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) +</programlisting> +</para> + +<para> + Some <acronym>IMMV</acronym>s have hidden columns which are added + automatically when a materialized view is created. Their name starts + with <literal>__ivm_</literal> and they contain information required + for maintaining the <acronym>IMMV</acronym>. Such columns are not visible + when the <acronym>IMMV</acronym> is accessed by <literal>SELECT *</literal> + but are visible if the column name is explicitly specified in the target + list. We can also see the hidden columns in <literal>\d</literal> + meta-commands of <command>psql</command> commands. +</para> + +<para> + In general, <acronym>IMMV</acronym>s allow faster updates of materialized + views at the price of slower updates to their base tables. Updates of + <acronym>IMMV</acronym> is slower because triggers will be invoked and the + view is updated in triggers per modification statement. +</para> + +<para> + For example, suppose a normal materialized view defined as below: + +<programlisting> +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 + +</programlisting> + + Updating a tuple in a base table of this materialized view is rapid but the + <command>REFRESH MATERIALIZED VIEW</command> command on this view takes a long time: + +<programlisting> +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) +</programlisting> +</para> + +<para> + On the other hand, after creating <acronym>IMMV</acronym> with the same view + definition as below: + +<programlisting> +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" +</programlisting> + + 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 + <command>REFRESH MATERIALIZED VIEW</command> command. + +<programlisting> +test=# UPDATE pgbench_accounts SET abalance = 1000 WHERE aid = 1; +UPDATE 1 +Time: 13.068 ms +</programlisting> + +</para> + +<para> + Appropriate indexes on <acronym>IMMV</acronym>s are necessary for + efficient <acronym>IVM</acronym> because it looks for tuples to be + updated in <acronym>IMMV</acronym>. If there are no indexes, it + will take a long time. +</para> + +<para> + Therefore, when <acronym>IMMV</acronym> 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. +</para> + +<para> + 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. +<programlisting> +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) +</programlisting> + +</para> + +<para> + <acronym>IVM</acronym> 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, <acronym>IVM</acronym> + 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, <acronym>IVM</acronym> is not effective and the cost of + maintenance can be larger than the <command>REFRESH MATERIALIZED VIEW</command> + command. In such situation, we can use <command>REFRESH MATERIALIZED VIEW</command> + and specify <literal>WITH NO DATA</literal> to disable immediate + maintenance before modifying a base table. After a base table modification, + execute the <command>REFRESH MATERIALIZED VIEW</command> (with <literal>WITH DATA</literal>) + command to refresh the view data and enable immediate maintenance. +</para> + +</sect2> + +<sect2 id="rules-ivm-support"> +<title>Supported View Definitions and Restrictions</title> + +<para> + Currently, we can create <acronym>IMMV</acronym>s using inner joins, and some + aggregates. However, several restrictions apply to the definition of IMMV. +</para> + +<sect3 id="rules-ivm-support-joins"> +<title>Joins</title> +<para> + Inner joins including self-join are supported. Outer joins are not supported. +</para> +</sect3> + +<sect3 id="rules-ivm-support-aggregates"> +<title>Aggregates</title> +<para> + Supported aggregate functions are <function>count</function>, <function>sum</function>, + <function>avg</function>, <function>min</function>, and <function>max</function>. + 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 <acronym>IMMV</acronym>. +</para> + +<para> + Note that for <function>min</function> or <function>max</function>, 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 <acronym>IMMV</acronym> containing + these functions. +</para> + +<para> + Also note that using <function>sum</function> or <function>avg</function> on + <type>real</type> (<type>float4</type>) type or <type>double precision</type> + (<type>float8</type>) type in <acronym>IMMV</acronym> is unsafe. This is + because aggregated values in <acronym>IMMV</acronym> can become different from + results calculated from base tables due to the limited precision of these types. + To avoid this problem, use the <type>numeric</type> type instead. +</para> + + <sect4 id="rules-ivm-restrictions-aggregates"> + <title>Restrictions on Aggregates</title> + <para> + There are the following restrictions: + <itemizedlist> + <listitem> + <para> + If we have a <literal>GROUP BY</literal> clause, expressions specified in + <literal>GROUP BY</literal> must appear in the target list. This is + how tuples to be updated in the <acronym>IMMV</acronym> are identified. + These attributes are used as scan keys for searching tuples in the + <acronym>IMMV</acronym>, so indexes on them are required for efficient + <acronym>IVM</acronym>. + </para> + </listitem> + + <listitem> + <para> + <literal>HAVING</literal> clause cannot be used. + </para> + </listitem> + </itemizedlist> + </para> + </sect4> +</sect3> + +<sect3 id="rules-ivm-general-restricitons"> +<title>Other General Restrictions</title> +<para> + There are other restrictions which generally apply to <acronym>IMMV</acronym>: + <itemizedlist> + <listitem> + <para> + Sub-queries cannot be used. + </para> + </listitem> + + <listitem> + <para> + CTEs cannot be used. + </para> + </listitem> + + <listitem> + <para> + Window functions cannot be used. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s must be based on simple base tables. It's not + supported to create them on top of views, materialized views, foreign tables, inhe. + </para> + </listitem> + + <listitem> + <para> + LIMIT and OFFSET clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s cannot contain system columns. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s cannot contain non-immutable functions. + </para> + </listitem> + + <listitem> + <para> + UNION/INTERSECT/EXCEPT clauses cannnot be used. + </para> + </listitem> + + <listitem> + <para> + DISTINCT ON clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + TABLESAMPLE parameter cannot be used. + </para> + </listitem> + + <listitem> + <para> + inheritance parent tables cannnot be used. + </para> + </listitem> + + <listitem> + <para> + VALUES clause cannnot be used. + </para> + </listitem> + + <listitem> + <para> + <literal>GROUPING SETS</literal> and <literal>FILTER</literal> clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + FOR UPDATE/SHARE cannot be used. + </para> + </listitem> + + <listitem> + <para> + targetlist cannot contain columns whose name start with <literal>__ivm_</literal>. + </para> + </listitem> + + <listitem> + <para> + targetlist cannot contain expressions which contain an aggregate in it. + </para> + </listitem> + + <listitem> + <para> + Logical replication is not supported, that is, even when a base table + at a publisher node is modified, <acronym>IMMV</acronym>s at subscriber + nodes are not updated. + </para> + </listitem> + + </itemizedlist> +</para> +</sect3> + +</sect2> + +<sect2 id="rules-ivm-distinct"> +<title><literal>DISTINCT</literal></title> + +<para> + <productname>PostgreSQL</productname> supports <acronym>IMMV</acronym> with + <literal>DISTINCT</literal>. For example, suppose a <acronym>IMMV</acronym> + defined with <literal>DISTINCT</literal> 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. +</para> + +<para> + Physically, an <acronym>IMMV</acronym> defined with <literal>DISTINCT</literal> + contains tuples after eliminating duplicates, and the multiplicity of each tuple + is stored in a hidden column named <literal>__ivm_count__</literal>. +</para> +</sect2> + +<sect2 id="rules-ivm-concurrent-transactions"> +<title>Concurrent Transactions</title> +<para> + Suppose an <acronym>IMMV</acronym> is defined on two base tables and each + table was modified in different a concurrent transaction simultaneously. + In the transaction which was committed first, <acronym>IMMV</acronym> 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, <literal>ExclusiveLock</literal> + is held on an <acronym>IMMV</acronym> immediately after a base table is + modified in <literal>READ COMMITTED</literal> mode to make sure that + the <acronym>IMMV</acronym> is updated in the latter transaction after + the former transaction is committed. In <literal>REPEATABLE READ</literal> + or <literal>SERIALIZABLE</literal> 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 + <acronym>IMMV</acronym> cannot be updated correctly in such situations. + However, as an exception if the view has only one base table and + <command>INSERT</command> is performed on the table, + the lock held on thew view is <literal>RowExclusiveLock</literal>. +</para> +</sect2> + +<sect2 id="rules-ivm-rls"> +<title>Row Level Security</title> +<para> + 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. +</para> +</sect2> + +</sect1> + <sect1 id="rules-update"> <title>Rules on <command>INSERT</command>, <command>UPDATE</command>, and <command>DELETE</command></title> diff --git a/doc/src/sgml/system-views.sgml b/doc/src/sgml/system-views.sgml index 2ebec6928d5..65d1e2041d2 100644 --- a/doc/src/sgml/system-views.sgml +++ b/doc/src/sgml/system-views.sgml @@ -2231,6 +2231,15 @@ SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx </para></entry> </row> + <row> + <entry role="catalog_table_entry"><para role="column_definition"> + <structfield>isimmv</structfield> <type>bool</type> + </para> + <para> + True if materialized view is incrementally maintainable + </para></entry> + </row> + <row> <entry role="catalog_table_entry"><para role="column_definition"> <structfield>definition</structfield> <type>text</type> -- 2.43.0 --Multipart=_Fri__29_May_2026_23_14_17_+0900_Te0o73X2VqYK57Gd Content-Type: text/x-diff; name="v37-0010-Add-regression-tests-for-Incremental-View-Mainte.patch" Content-Disposition: attachment; filename="v37-0010-Add-regression-tests-for-Incremental-View-Mainte.patch" Content-Transfer-Encoding: 7bit ^ permalink raw reply [nested|flat] 22+ messages in thread
* [PATCH v38 11/11] Add documentations about Incremental View Maintenance @ 2019-12-20 01:25 Yugo Nagata <[email protected]> 0 siblings, 0 replies; 22+ messages in thread From: Yugo Nagata @ 2019-12-20 01:25 UTC (permalink / raw) --- 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 4b474c13917..9b1c88161a7 100644 --- a/doc/src/sgml/catalogs.sgml +++ b/doc/src/sgml/catalogs.sgml @@ -2276,6 +2276,15 @@ SCRAM-SHA-256$<replaceable><iteration count></replaceable>:<replaceable>&l </para></entry> </row> + <row> + <entry role="catalog_table_entry"><para role="column_definition"> + <structfield>relisivm</structfield> <type>bool</type> + </para> + <para> + True if relation is incrementally maintainable materialized view + </para></entry> + </row> + <row> <entry role="catalog_table_entry"><para role="column_definition"> <structfield>relrewrite</structfield> <type>oid</type> diff --git a/doc/src/sgml/ref/create_materialized_view.sgml b/doc/src/sgml/ref/create_materialized_view.sgml index 62d897931c3..f49db209558 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 <refsynopsisdiv> <synopsis> -CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> +CREATE [ INCREMENTAL ] MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> [ (<replaceable>column_name</replaceable> [, ...] ) ] [ USING <replaceable class="parameter">method</replaceable> ] [ WITH ( <replaceable class="parameter">storage_parameter</replaceable> [= <replaceable class="parameter">value</replaceable>] [, ... ] ) ] @@ -60,6 +60,125 @@ CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> <title>Parameters</title> <variablelist> + <varlistentry> + <term><literal>INCREMENTAL</literal></term> + <listitem> + <para> + 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). + </para> + <para> + When <acronym>IMMV</acronym> is defined without using <command>WITH NO DATA</command>, + 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. + </para> + <para> + There are restrictions of query definitions allowed to use this + option. The following are supported in query definitions for IMMV: + <itemizedlist> + + <listitem> + <para> + Inner joins (including self-joins). + </para> + </listitem> + + <listitem> + <para> + Some built-in aggregate functions (count, sum, avg, min, max) without a HAVING + clause. + </para> + </listitem> + </itemizedlist> + + Unsupported queries with this option include the following: + + <itemizedlist> + <listitem> + <para> + Outer joins. + </para> + </listitem> + + <listitem> + <para> + Sub-queries. + </para> + </listitem> + + <listitem> + <para> + Aggregate functions other than built-in count, sum, avg, min and max. + </para> + </listitem> + <listitem> + <para> + Aggregate functions with a HAVING clause. + </para> + </listitem> + <listitem> + <para> + DISTINCT ON, WINDOW, VALUES, LIMIT and OFFSET clause. + </para> + </listitem> + </itemizedlist> + + Other restrictions include: + <itemizedlist> + + <listitem> + <para> + IMMVs must be based on simple base tables. It's not supported to + create them on top of views or materialized views. + </para> + </listitem> + + <listitem> + <para> + It is not supported to include system columns in an IMMV. + <programlisting> +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 + </programlisting> + </para> + </listitem> + + <listitem> + <para> + Non-immutable functions are not supported. + <programlisting> +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 + </programlisting> + </para> + </listitem> + + <listitem> + <para> + IMMVs do not support expressions that contains aggregates + </para> + </listitem> + + <listitem> + <para> + Logical replication does not support IMMVs. + </para> + </listitem> + + </itemizedlist> + + </para> + </listitem> + </varlistentry> + <varlistentry> <term><literal>IF NOT EXISTS</literal></term> <listitem> @@ -157,7 +276,8 @@ CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> 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 <command>REFRESH - MATERIALIZED VIEW</command> is used. + MATERIALIZED VIEW</command> is used. Also, if the view is IMMV, + triggers for maintaining the view are not created. </para> </listitem> </varlistentry> diff --git a/doc/src/sgml/ref/refresh_materialized_view.sgml b/doc/src/sgml/ref/refresh_materialized_view.sgml index 8ed43ade803..a4d729bdf0f 100644 --- a/doc/src/sgml/ref/refresh_materialized_view.sgml +++ b/doc/src/sgml/ref/refresh_materialized_view.sgml @@ -36,9 +36,13 @@ REFRESH MATERIALIZED VIEW [ CONCURRENTLY ] <replaceable class="parameter">name</ privilege on the materialized view. The old contents are discarded. If <literal>WITH DATA</literal> 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 <literal>WITH NO DATA</literal> 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 <literal>WITH NO DATA</literal> 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. </para> <para> <literal>CONCURRENTLY</literal> and <literal>WITH NO DATA</literal> may not diff --git a/doc/src/sgml/rules.sgml b/doc/src/sgml/rules.sgml index 7f23962f524..da9ad3c6316 100644 --- a/doc/src/sgml/rules.sgml +++ b/doc/src/sgml/rules.sgml @@ -1103,6 +1103,443 @@ SELECT word FROM words ORDER BY word <-> 'caterpiler' LIMIT 10; </sect1> +<sect1 id="rules-ivm"> +<title>Incremental View Maintenance</title> + +<indexterm zone="rules-ivm"> + <primary>incremental view maintenance</primary> +</indexterm> + +<indexterm zone="rules-ivm"> + <primary>materialized view</primary> + <secondary>incremental view maintenance</secondary> +</indexterm> + +<indexterm zone="rules-ivm"> + <primary>view</primary> + <secondary>incremental view maintenance</secondary> +</indexterm> + +<sect2 id="rules-ivm-overview"> +<title>Overview</title> + +<para> + Incremental View Maintenance (<acronym>IVM</acronym>) 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 + <command>REFRESH MATERIALIZED VIEW</command> does. <acronym>IVM</acronym> + can update materialized views more efficiently than recomputation when only + small parts of the view are changed. +</para> + +<para> + 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 <command>REFRESH + MATERIALIZED VIEW</command>, or periodically in background, and so on. + <productname>PostgreSQL</productname> currently implements only a kind of + immediate maintenance, in which materialized views are updated immediately + in AFTER triggers when a base table is modified. +</para> + +<para> + To create materialized views supporting <acronym>IVM</acronym>, use the + <command>CREATE INCREMENTAL MATERIALIZED VIEW</command>, for example: +<programlisting> +CREATE <emphasis>INCREMENTAL</emphasis> MATERIALIZED VIEW mymatview AS SELECT * FROM mytab; +</programlisting> + When a materialized view is created with the <literal>INCREMENTAL</literal> + 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 + (<acronym>IMMV</acronym>). +<programlisting> +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) +</programlisting> +</para> + +<para> + Some <acronym>IMMV</acronym>s have hidden columns which are added + automatically when a materialized view is created. Their name starts + with <literal>__ivm_</literal> and they contain information required + for maintaining the <acronym>IMMV</acronym>. Such columns are not visible + when the <acronym>IMMV</acronym> is accessed by <literal>SELECT *</literal> + but are visible if the column name is explicitly specified in the target + list. We can also see the hidden columns in <literal>\d</literal> + meta-commands of <command>psql</command> commands. +</para> + +<para> + In general, <acronym>IMMV</acronym>s allow faster updates of materialized + views at the price of slower updates to their base tables. Updates of + <acronym>IMMV</acronym> is slower because triggers will be invoked and the + view is updated in triggers per modification statement. +</para> + +<para> + For example, suppose a normal materialized view defined as below: + +<programlisting> +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 + +</programlisting> + + Updating a tuple in a base table of this materialized view is rapid but the + <command>REFRESH MATERIALIZED VIEW</command> command on this view takes a long time: + +<programlisting> +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) +</programlisting> +</para> + +<para> + On the other hand, after creating <acronym>IMMV</acronym> with the same view + definition as below: + +<programlisting> +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" +</programlisting> + + 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 + <command>REFRESH MATERIALIZED VIEW</command> command. + +<programlisting> +test=# UPDATE pgbench_accounts SET abalance = 1000 WHERE aid = 1; +UPDATE 1 +Time: 13.068 ms +</programlisting> + +</para> + +<para> + Appropriate indexes on <acronym>IMMV</acronym>s are necessary for + efficient <acronym>IVM</acronym> because it looks for tuples to be + updated in <acronym>IMMV</acronym>. If there are no indexes, it + will take a long time. +</para> + +<para> + Therefore, when <acronym>IMMV</acronym> 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. +</para> + +<para> + 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. +<programlisting> +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) +</programlisting> + +</para> + +<para> + <acronym>IVM</acronym> 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, <acronym>IVM</acronym> + 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, <acronym>IVM</acronym> is not effective and the cost of + maintenance can be larger than the <command>REFRESH MATERIALIZED VIEW</command> + command. In such situation, we can use <command>REFRESH MATERIALIZED VIEW</command> + and specify <literal>WITH NO DATA</literal> to disable immediate + maintenance before modifying a base table. After a base table modification, + execute the <command>REFRESH MATERIALIZED VIEW</command> (with <literal>WITH DATA</literal>) + command to refresh the view data and enable immediate maintenance. +</para> + +</sect2> + +<sect2 id="rules-ivm-support"> +<title>Supported View Definitions and Restrictions</title> + +<para> + Currently, we can create <acronym>IMMV</acronym>s using inner joins, and some + aggregates. However, several restrictions apply to the definition of IMMV. +</para> + +<sect3 id="rules-ivm-support-joins"> +<title>Joins</title> +<para> + Inner joins including self-join are supported. Outer joins are not supported. +</para> +</sect3> + +<sect3 id="rules-ivm-support-aggregates"> +<title>Aggregates</title> +<para> + Supported aggregate functions are <function>count</function>, <function>sum</function>, + <function>avg</function>, <function>min</function>, and <function>max</function>. + 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 <acronym>IMMV</acronym>. +</para> + +<para> + Note that for <function>min</function> or <function>max</function>, 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 <acronym>IMMV</acronym> containing + these functions. +</para> + +<para> + Also note that using <function>sum</function> or <function>avg</function> on + <type>real</type> (<type>float4</type>) type or <type>double precision</type> + (<type>float8</type>) type in <acronym>IMMV</acronym> is unsafe. This is + because aggregated values in <acronym>IMMV</acronym> can become different from + results calculated from base tables due to the limited precision of these types. + To avoid this problem, use the <type>numeric</type> type instead. +</para> + + <sect4 id="rules-ivm-restrictions-aggregates"> + <title>Restrictions on Aggregates</title> + <para> + There are the following restrictions: + <itemizedlist> + <listitem> + <para> + If we have a <literal>GROUP BY</literal> clause, expressions specified in + <literal>GROUP BY</literal> must appear in the target list. This is + how tuples to be updated in the <acronym>IMMV</acronym> are identified. + These attributes are used as scan keys for searching tuples in the + <acronym>IMMV</acronym>, so indexes on them are required for efficient + <acronym>IVM</acronym>. + </para> + </listitem> + + <listitem> + <para> + <literal>HAVING</literal> clause cannot be used. + </para> + </listitem> + </itemizedlist> + </para> + </sect4> +</sect3> + +<sect3 id="rules-ivm-general-restricitons"> +<title>Other General Restrictions</title> +<para> + There are other restrictions which generally apply to <acronym>IMMV</acronym>: + <itemizedlist> + <listitem> + <para> + Sub-queries cannot be used. + </para> + </listitem> + + <listitem> + <para> + CTEs cannot be used. + </para> + </listitem> + + <listitem> + <para> + Window functions cannot be used. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s must be based on simple base tables. It's not + supported to create them on top of views, materialized views, foreign tables, inhe. + </para> + </listitem> + + <listitem> + <para> + LIMIT and OFFSET clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s cannot contain system columns. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s cannot contain non-immutable functions. + </para> + </listitem> + + <listitem> + <para> + UNION/INTERSECT/EXCEPT clauses cannnot be used. + </para> + </listitem> + + <listitem> + <para> + DISTINCT ON clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + TABLESAMPLE parameter cannot be used. + </para> + </listitem> + + <listitem> + <para> + inheritance parent tables cannnot be used. + </para> + </listitem> + + <listitem> + <para> + VALUES clause cannnot be used. + </para> + </listitem> + + <listitem> + <para> + <literal>GROUPING SETS</literal> and <literal>FILTER</literal> clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + FOR UPDATE/SHARE cannot be used. + </para> + </listitem> + + <listitem> + <para> + targetlist cannot contain columns whose name start with <literal>__ivm_</literal>. + </para> + </listitem> + + <listitem> + <para> + targetlist cannot contain expressions which contain an aggregate in it. + </para> + </listitem> + + <listitem> + <para> + Logical replication is not supported, that is, even when a base table + at a publisher node is modified, <acronym>IMMV</acronym>s at subscriber + nodes are not updated. + </para> + </listitem> + + </itemizedlist> +</para> +</sect3> + +</sect2> + +<sect2 id="rules-ivm-distinct"> +<title><literal>DISTINCT</literal></title> + +<para> + <productname>PostgreSQL</productname> supports <acronym>IMMV</acronym> with + <literal>DISTINCT</literal>. For example, suppose a <acronym>IMMV</acronym> + defined with <literal>DISTINCT</literal> 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. +</para> + +<para> + Physically, an <acronym>IMMV</acronym> defined with <literal>DISTINCT</literal> + contains tuples after eliminating duplicates, and the multiplicity of each tuple + is stored in a hidden column named <literal>__ivm_count__</literal>. +</para> +</sect2> + +<sect2 id="rules-ivm-concurrent-transactions"> +<title>Concurrent Transactions</title> +<para> + Suppose an <acronym>IMMV</acronym> is defined on two base tables and each + table was modified in different a concurrent transaction simultaneously. + In the transaction which was committed first, <acronym>IMMV</acronym> 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, <literal>ExclusiveLock</literal> + is held on an <acronym>IMMV</acronym> immediately after a base table is + modified in <literal>READ COMMITTED</literal> mode to make sure that + the <acronym>IMMV</acronym> is updated in the latter transaction after + the former transaction is committed. In <literal>REPEATABLE READ</literal> + or <literal>SERIALIZABLE</literal> 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 + <acronym>IMMV</acronym> cannot be updated correctly in such situations. + However, as an exception if the view has only one base table and + <command>INSERT</command> is performed on the table, + the lock held on thew view is <literal>RowExclusiveLock</literal>. +</para> +</sect2> + +<sect2 id="rules-ivm-rls"> +<title>Row Level Security</title> +<para> + 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. +</para> +</sect2> + +</sect1> + <sect1 id="rules-update"> <title>Rules on <command>INSERT</command>, <command>UPDATE</command>, and <command>DELETE</command></title> diff --git a/doc/src/sgml/system-views.sgml b/doc/src/sgml/system-views.sgml index 2ebec6928d5..65d1e2041d2 100644 --- a/doc/src/sgml/system-views.sgml +++ b/doc/src/sgml/system-views.sgml @@ -2231,6 +2231,15 @@ SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx </para></entry> </row> + <row> + <entry role="catalog_table_entry"><para role="column_definition"> + <structfield>isimmv</structfield> <type>bool</type> + </para> + <para> + True if materialized view is incrementally maintainable + </para></entry> + </row> + <row> <entry role="catalog_table_entry"><para role="column_definition"> <structfield>definition</structfield> <type>text</type> -- 2.43.0 --Multipart=_Wed__1_Jul_2026_00_04_01_+0900_OVSy2WWK_9aByzDJ Content-Type: text/x-diff; name="v38-0010-Add-regression-tests-for-Incremental-View-Mainte.patch" Content-Disposition: attachment; filename="v38-0010-Add-regression-tests-for-Incremental-View-Mainte.patch" Content-Transfer-Encoding: 7bit ^ permalink raw reply [nested|flat] 22+ messages in thread
* [PATCH v28 11/11] Add documentations about Incremental View Maintenance @ 2019-12-20 01:25 Yugo Nagata <[email protected]> 0 siblings, 0 replies; 22+ messages in thread From: Yugo Nagata @ 2019-12-20 01:25 UTC (permalink / raw) --- doc/src/sgml/catalogs.sgml | 9 + .../sgml/ref/create_materialized_view.sgml | 131 +++++- .../sgml/ref/refresh_materialized_view.sgml | 8 +- doc/src/sgml/rules.sgml | 443 ++++++++++++++++++ 4 files changed, 587 insertions(+), 4 deletions(-) diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml index ed32ca0349..51378358a1 100644 --- a/doc/src/sgml/catalogs.sgml +++ b/doc/src/sgml/catalogs.sgml @@ -2223,6 +2223,15 @@ SCRAM-SHA-256$<replaceable><iteration count></replaceable>:<replaceable>&l </para></entry> </row> + <row> + <entry role="catalog_table_entry"><para role="column_definition"> + <structfield>relisivm</structfield> <type>bool</type> + </para> + <para> + True if materialized view enables incremental view maintenance + </para></entry> + </row> + <row> <entry role="catalog_table_entry"><para role="column_definition"> <structfield>relrewrite</structfield> <type>oid</type> diff --git a/doc/src/sgml/ref/create_materialized_view.sgml b/doc/src/sgml/ref/create_materialized_view.sgml index 0d2fea2b97..52a4d206b1 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 <refsynopsisdiv> <synopsis> -CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> +CREATE [ INCREMENTAL ] MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> [ (<replaceable>column_name</replaceable> [, ...] ) ] [ USING <replaceable class="parameter">method</replaceable> ] [ WITH ( <replaceable class="parameter">storage_parameter</replaceable> [= <replaceable class="parameter">value</replaceable>] [, ... ] ) ] @@ -60,6 +60,132 @@ CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> <title>Parameters</title> <variablelist> + <varlistentry> + <term><literal>INCREMENTAL</literal></term> + <listitem> + <para> + 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). + </para> + <para> + When <acronym>IMMV</acronym> is defined without using <command>WITH NO DATA</command>, + 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. + </para> + <para> + There are restrictions of query definitions allowed to use this + option. The following are supported in query definitions for IMMV: + <itemizedlist> + + <listitem> + <para> + Inner joins (including self-joins). + </para> + </listitem> + + <listitem> + <para> + Some built-in aggregate functions (count, sum, avg, min, max) without a HAVING + clause. + </para> + </listitem> + </itemizedlist> + + Unsupported queries with this option include the following: + + <itemizedlist> + <listitem> + <para> + Outer joins. + </para> + </listitem> + + <listitem> + <para> + Sub-queries. + </para> + </listitem> + + <listitem> + <para> + Aggregate functions other than built-in count, sum, avg, min and max. + </para> + </listitem> + <listitem> + <para> + Aggregate functions with a HAVING clause. + </para> + </listitem> + <listitem> + <para> + DISTINCT ON, WINDOW, VALUES, LIMIT and OFFSET clause. + </para> + </listitem> + </itemizedlist> + + Other restrictions include: + <itemizedlist> + + <listitem> + <para> + IMMVs must be based on simple base tables. It's not supported to + create them on top of views or materialized views. + </para> + </listitem> + + <listitem> + <para> + When the TRUNCATE command is executed on a base table, + no changes are made to the materialized view. + </para> + </listitem> + + <listitem> + <para> + It is not supported to include system columns in an IMMV. + <programlisting> +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 + </programlisting> + </para> + </listitem> + + <listitem> + <para> + Non-immutable functions are not supported. + <programlisting> +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 + </programlisting> + </para> + </listitem> + + <listitem> + <para> + IMMVs do not support expressions that contains aggregates + </para> + </listitem> + + <listitem> + <para> + Logical replication does not support IMMVs. + </para> + </listitem> + + </itemizedlist> + + </para> + </listitem> + </varlistentry> + <varlistentry> <term><literal>IF NOT EXISTS</literal></term> <listitem> @@ -155,7 +281,8 @@ CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> 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 <command>REFRESH - MATERIALIZED VIEW</command> is used. + MATERIALIZED VIEW</command> is used. Also, if the view is IMMV, + triggers for maintaining the view are not created. </para> </listitem> </varlistentry> diff --git a/doc/src/sgml/ref/refresh_materialized_view.sgml b/doc/src/sgml/ref/refresh_materialized_view.sgml index 4d79b6ae7f..4e27e29e35 100644 --- a/doc/src/sgml/ref/refresh_materialized_view.sgml +++ b/doc/src/sgml/ref/refresh_materialized_view.sgml @@ -38,9 +38,13 @@ REFRESH MATERIALIZED VIEW [ CONCURRENTLY ] <replaceable class="parameter">name</ privilege on the materialized view. The old contents are discarded. If <literal>WITH DATA</literal> 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 <literal>WITH NO DATA</literal> 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 <literal>WITH NO DATA</literal> 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. </para> <para> <literal>CONCURRENTLY</literal> and <literal>WITH NO DATA</literal> may not diff --git a/doc/src/sgml/rules.sgml b/doc/src/sgml/rules.sgml index d229b94d39..d000beacdf 100644 --- a/doc/src/sgml/rules.sgml +++ b/doc/src/sgml/rules.sgml @@ -1096,6 +1096,449 @@ SELECT word FROM words ORDER BY word <-> 'caterpiler' LIMIT 10; </sect1> +<sect1 id="rules-ivm"> +<title>Incremental View Maintenance</title> + +<indexterm zone="rules-ivm"> + <primary>incremental view maintenance</primary> +</indexterm> + +<indexterm zone="rules-ivm"> + <primary>materialized view</primary> + <secondary>incremental view maintenance</secondary> +</indexterm> + +<indexterm zone="rules-ivm"> + <primary>view</primary> + <secondary>incremental view maintenance</secondary> +</indexterm> + +<sect2 id="rules-ivm-overview"> +<title>Overview</title> + +<para> + Incremental View Maintenance (<acronym>IVM</acronym>) 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 + <command>REFRESH MATERIALIZED VIEW</command> does. <acronym>IVM</acronym> + can update materialized views more efficiently than recomputation when only + small parts of the view are changed. +</para> + +<para> + 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 <command>REFRESH + MATERIALIZED VIEW</command>, or periodically in background, and so on. + <productname>PostgreSQL</productname> currently implements only a kind of + immediate maintenance, in which materialized views are updated immediately + in AFTER triggers when a base table is modified. +</para> + +<para> + To create materialized views supporting <acronym>IVM</acronym>, use the + <command>CREATE INCREMENTAL MATERIALIZED VIEW</command>, for example: +<programlisting> +CREATE <emphasis>INCREMENTAL</emphasis> MATERIALIZED VIEW mymatview AS SELECT * FROM mytab; +</programlisting> + When a materialized view is created with the <literal>INCREMENTAL</literal> + 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 + (<acronym>IMMV</acronym>). +<programlisting> +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) +</programlisting> +</para> + +<para> + Some <acronym>IMMV</acronym>s have hidden columns which are added + automatically when a materialized view is created. Their name starts + with <literal>__ivm_</literal> and they contain information required + for maintaining the <acronym>IMMV</acronym>. Such columns are not visible + when the <acronym>IMMV</acronym> is accessed by <literal>SELECT *</literal> + but are visible if the column name is explicitly specified in the target + list. We can also see the hidden columns in <literal>\d</literal> + meta-commands of <command>psql</command> commands. +</para> + +<para> + In general, <acronym>IMMV</acronym>s allow faster updates of materialized + views at the price of slower updates to their base tables. Updates of + <acronym>IMMV</acronym> is slower because triggers will be invoked and the + view is updated in triggers per modification statement. +</para> + +<para> + For example, suppose a normal materialized view defined as below: + +<programlisting> +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 + +</programlisting> + + Updating a tuple in a base table of this materialized view is rapid but the + <command>REFRESH MATERIALIZED VIEW</command> command on this view takes a long time: + +<programlisting> +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) +</programlisting> +</para> + +<para> + On the other hand, after creating <acronym>IMMV</acronym> with the same view + definition as below: + +<programlisting> +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" +</programlisting> + + 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 + <command>REFRESH MATERIALIZED VIEW</command> command. + +<programlisting> +test=# UPDATE pgbench_accounts SET abalance = 1000 WHERE aid = 1; +UPDATE 1 +Time: 13.068 ms +</programlisting> + +</para> + +<para> + Appropriate indexes on <acronym>IMMV</acronym>s are necessary for + efficient <acronym>IVM</acronym> because it looks for tuples to be + updated in <acronym>IMMV</acronym>. If there are no indexes, it + will take a long time. +</para> + +<para> + Therefore, when <acronym>IMMV</acronym> 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. +</para> + +<para> + 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. +<programlisting> +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) +</programlisting> + +</para> + +<para> + <acronym>IVM</acronym> 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, <acronym>IVM</acronym> + 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, <acronym>IVM</acronym> is not effective and the cost of + maintenance can be larger than the <command>REFRESH MATERIALIZED VIEW</command> + command. In such situation, we can use <command>REFRESH MATERIALIZED VIEW</command> + and specify <literal>WITH NO DATA</literal> to disable immediate + maintenance before modifying a base table. After a base table modification, + execute the <command>REFRESH MATERIALIZED VIEW</command> (with <literal>WITH DATA</literal>) + command to refresh the view data and enable immediate maintenance. +</para> + +</sect2> + +<sect2> +<title>Supported View Definitions and Restrictions</title> + +<para> + Currently, we can create <acronym>IMMV</acronym>s using inner joins, and some + aggregates. However, several restrictions apply to the definition of IMMV. +</para> + +<sect3> +<title>Joins</title> +<para> + Inner joins including self-join are supported. Outer joins are not supported. +</para> +</sect3> + +<sect3> +<title>Aggregates</title> +<para> + Supported aggregate functions are <function>count</function>, <function>sum</function>, + <function>avg</function>, <function>min</function>, and <function>max</function>. + 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 <acronym>IMMV</acronym>. +</para> + +<para> + Note that for <function>min</function> or <function>max</function>, 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 <acronym>IMMV</acronym> containing + these functions. +</para> + +<para> + Also note that using <function>sum</function> or <function>avg</function> on + <type>real</type> (<type>float4</type>) type or <type>double precision</type> + (<type>float8</type>) type in <acronym>IMMV</acronym> is unsafe. This is + because aggregated values in <acronym>IMMV</acronym> can become different from + results calculated from base tables due to the limited precision of these types. + To avoid this problem, use the <type>numeric</type> type instead. +</para> + + <sect4> + <title>Restrictions on Aggregates</title> + <para> + There are the following restrictions: + <itemizedlist> + <listitem> + <para> + If we have a <literal>GROUP BY</literal> clause, expressions specified in + <literal>GROUP BY</literal> must appear in the target list. This is + how tuples to be updated in the <acronym>IMMV</acronym> are identified. + These attributes are used as scan keys for searching tuples in the + <acronym>IMMV</acronym>, so indexes on them are required for efficient + <acronym>IVM</acronym>. + </para> + </listitem> + + <listitem> + <para> + <literal>HAVING</literal> clause cannot be used. + </para> + </listitem> + </itemizedlist> + </para> + </sect4> +</sect3> + +<sect3> +<title>Other General Restrictions</title> +<para> + There are other restrictions which generally apply to <acronym>IMMV</acronym>: + <itemizedlist> + <listitem> + <para> + Sub-queries cannot be used. + </para> + </listitem> + + <listitem> + <para> + CTEs cannot be used. + </para> + </listitem> + + <listitem> + <para> + Window functions cannot be used. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s must be based on simple base tables. It's not + supported to create them on top of views, materialized views, foreign tables, inhe. + </para> + </listitem> + + <listitem> + <para> + LIMIT and OFFSET clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s cannot contain system columns. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s cannot contain non-immutable functions. + </para> + </listitem> + + <listitem> + <para> + UNION/INTERSECT/EXCEPT clauses cannnot be used. + </para> + </listitem> + + <listitem> + <para> + DISTINCT ON clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + TABLESAMPLE parameter cannot be used. + </para> + </listitem> + + <listitem> + <para> + inheritance parent tables cannnot be used. + </para> + </listitem> + + <listitem> + <para> + VALUES clause cannnot be used. + </para> + </listitem> + + <listitem> + <para> + <literal>GROUPING SETS</literal> and <literal>FILTER</literal> clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + FOR UPDATE/SHARE cannot be used. + </para> + </listitem> + + <listitem> + <para> + targetlist cannot contain columns whose name start with <literal>__ivm_</literal>. + </para> + </listitem> + + <listitem> + <para> + targetlist cannot contain expressions which contain an aggregate in it. + </para> + </listitem> + + <listitem> + <para> + Logical replication is not supported, that is, even when a base table + at a publisher node is modified, <acronym>IMMV</acronym>s at subscriber + nodes are not updated. + </para> + </listitem> + + <listitem> + <para> + When the <literal>TRUNCATE</literal> command is executed on a base table, + nothing is changed on the <acronym>IMMV</acronym>. + </para> + </listitem> + + </itemizedlist> +</para> +</sect3> + +</sect2> + +<sect2> +<title><literal>DISTINCT</literal></title> + +<para> + <productname>PostgreSQL</productname> supports <acronym>IMMV</acronym> with + <literal>DISTINCT</literal>. For example, suppose a <acronym>IMMV</acronym> + defined with <literal>DISTINCT</literal> 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. +</para> + +<para> + Physically, an <acronym>IMMV</acronym> defined with <literal>DISTINCT</literal> + contains tuples after eliminating duplicates, and the multiplicity of each tuple + is stored in a hidden column named <literal>__ivm_count__</literal>. +</para> +</sect2> + +<sect2> +<title>Concurrent Transactions</title> +<para> + Suppose an <acronym>IMMV</acronym> is defined on two base tables and each + table was modified in different a concurrent transaction simultaneously. + In the transaction which was committed first, <acronym>IMMV</acronym> 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, <literal>ExclusiveLock</literal> + is held on an <acronym>IMMV</acronym> immediately after a base table is + modified in <literal>READ COMMITTED</literal> mode to make sure that + the <acronym>IMMV</acronym> is updated in the latter transaction after + the former transaction is committed. In <literal>REPEATABLE READ</literal> + or <literal>SERIALIZABLE</literal> 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 + <acronym>IMMV</acronym> cannot be updated correctly in such situations. + However, as an exception if the view has only one base table, + the lock held on thew view is <literal>RowExclusiveLock</literal>. +</para> +</sect2> + +<sect2> +<title>Row Level Security</title> +<para> + 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. +</para> +</sect2> + +</sect1> + <sect1 id="rules-update"> <title>Rules on <command>INSERT</command>, <command>UPDATE</command>, and <command>DELETE</command></title> -- 2.25.1 --Multipart=_Thu__1_Jun_2023_23_59_09_+0900_/G5+8nG46.f1T42K-- ^ permalink raw reply [nested|flat] 22+ messages in thread
* [PATCH v30 11/11] Add documentations about Incremental View Maintenance @ 2019-12-20 01:25 Yugo Nagata <[email protected]> 0 siblings, 0 replies; 22+ messages in thread From: Yugo Nagata @ 2019-12-20 01:25 UTC (permalink / raw) --- 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 880f717b10..f8df2951a8 100644 --- a/doc/src/sgml/catalogs.sgml +++ b/doc/src/sgml/catalogs.sgml @@ -2224,6 +2224,15 @@ SCRAM-SHA-256$<replaceable><iteration count></replaceable>:<replaceable>&l </para></entry> </row> + <row> + <entry role="catalog_table_entry"><para role="column_definition"> + <structfield>relisivm</structfield> <type>bool</type> + </para> + <para> + True if relation is incrementally maintainable materialized view + </para></entry> + </row> + <row> <entry role="catalog_table_entry"><para role="column_definition"> <structfield>relrewrite</structfield> <type>oid</type> 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 <refsynopsisdiv> <synopsis> -CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> +CREATE [ INCREMENTAL ] MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> [ (<replaceable>column_name</replaceable> [, ...] ) ] [ USING <replaceable class="parameter">method</replaceable> ] [ WITH ( <replaceable class="parameter">storage_parameter</replaceable> [= <replaceable class="parameter">value</replaceable>] [, ... ] ) ] @@ -60,6 +60,125 @@ CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> <title>Parameters</title> <variablelist> + <varlistentry> + <term><literal>INCREMENTAL</literal></term> + <listitem> + <para> + 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). + </para> + <para> + When <acronym>IMMV</acronym> is defined without using <command>WITH NO DATA</command>, + 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. + </para> + <para> + There are restrictions of query definitions allowed to use this + option. The following are supported in query definitions for IMMV: + <itemizedlist> + + <listitem> + <para> + Inner joins (including self-joins). + </para> + </listitem> + + <listitem> + <para> + Some built-in aggregate functions (count, sum, avg, min, max) without a HAVING + clause. + </para> + </listitem> + </itemizedlist> + + Unsupported queries with this option include the following: + + <itemizedlist> + <listitem> + <para> + Outer joins. + </para> + </listitem> + + <listitem> + <para> + Sub-queries. + </para> + </listitem> + + <listitem> + <para> + Aggregate functions other than built-in count, sum, avg, min and max. + </para> + </listitem> + <listitem> + <para> + Aggregate functions with a HAVING clause. + </para> + </listitem> + <listitem> + <para> + DISTINCT ON, WINDOW, VALUES, LIMIT and OFFSET clause. + </para> + </listitem> + </itemizedlist> + + Other restrictions include: + <itemizedlist> + + <listitem> + <para> + IMMVs must be based on simple base tables. It's not supported to + create them on top of views or materialized views. + </para> + </listitem> + + <listitem> + <para> + It is not supported to include system columns in an IMMV. + <programlisting> +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 + </programlisting> + </para> + </listitem> + + <listitem> + <para> + Non-immutable functions are not supported. + <programlisting> +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 + </programlisting> + </para> + </listitem> + + <listitem> + <para> + IMMVs do not support expressions that contains aggregates + </para> + </listitem> + + <listitem> + <para> + Logical replication does not support IMMVs. + </para> + </listitem> + + </itemizedlist> + + </para> + </listitem> + </varlistentry> + <varlistentry> <term><literal>IF NOT EXISTS</literal></term> <listitem> @@ -155,7 +274,8 @@ CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> 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 <command>REFRESH - MATERIALIZED VIEW</command> is used. + MATERIALIZED VIEW</command> is used. Also, if the view is IMMV, + triggers for maintaining the view are not created. </para> </listitem> </varlistentry> diff --git a/doc/src/sgml/ref/refresh_materialized_view.sgml b/doc/src/sgml/ref/refresh_materialized_view.sgml index 7a019162c3..dd894a2324 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 ] <replaceable class="parameter">name</ owner of the materialized view. The old contents are discarded. If <literal>WITH DATA</literal> 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 <literal>WITH NO DATA</literal> 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 <literal>WITH NO DATA</literal> 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. </para> <para> <literal>CONCURRENTLY</literal> and <literal>WITH NO DATA</literal> may not diff --git a/doc/src/sgml/rules.sgml b/doc/src/sgml/rules.sgml index 784c16e76e..149bb99b1c 100644 --- a/doc/src/sgml/rules.sgml +++ b/doc/src/sgml/rules.sgml @@ -1098,6 +1098,443 @@ SELECT word FROM words ORDER BY word <-> 'caterpiler' LIMIT 10; </sect1> +<sect1 id="rules-ivm"> +<title>Incremental View Maintenance</title> + +<indexterm zone="rules-ivm"> + <primary>incremental view maintenance</primary> +</indexterm> + +<indexterm zone="rules-ivm"> + <primary>materialized view</primary> + <secondary>incremental view maintenance</secondary> +</indexterm> + +<indexterm zone="rules-ivm"> + <primary>view</primary> + <secondary>incremental view maintenance</secondary> +</indexterm> + +<sect2 id="rules-ivm-overview"> +<title>Overview</title> + +<para> + Incremental View Maintenance (<acronym>IVM</acronym>) 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 + <command>REFRESH MATERIALIZED VIEW</command> does. <acronym>IVM</acronym> + can update materialized views more efficiently than recomputation when only + small parts of the view are changed. +</para> + +<para> + 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 <command>REFRESH + MATERIALIZED VIEW</command>, or periodically in background, and so on. + <productname>PostgreSQL</productname> currently implements only a kind of + immediate maintenance, in which materialized views are updated immediately + in AFTER triggers when a base table is modified. +</para> + +<para> + To create materialized views supporting <acronym>IVM</acronym>, use the + <command>CREATE INCREMENTAL MATERIALIZED VIEW</command>, for example: +<programlisting> +CREATE <emphasis>INCREMENTAL</emphasis> MATERIALIZED VIEW mymatview AS SELECT * FROM mytab; +</programlisting> + When a materialized view is created with the <literal>INCREMENTAL</literal> + 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 + (<acronym>IMMV</acronym>). +<programlisting> +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) +</programlisting> +</para> + +<para> + Some <acronym>IMMV</acronym>s have hidden columns which are added + automatically when a materialized view is created. Their name starts + with <literal>__ivm_</literal> and they contain information required + for maintaining the <acronym>IMMV</acronym>. Such columns are not visible + when the <acronym>IMMV</acronym> is accessed by <literal>SELECT *</literal> + but are visible if the column name is explicitly specified in the target + list. We can also see the hidden columns in <literal>\d</literal> + meta-commands of <command>psql</command> commands. +</para> + +<para> + In general, <acronym>IMMV</acronym>s allow faster updates of materialized + views at the price of slower updates to their base tables. Updates of + <acronym>IMMV</acronym> is slower because triggers will be invoked and the + view is updated in triggers per modification statement. +</para> + +<para> + For example, suppose a normal materialized view defined as below: + +<programlisting> +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 + +</programlisting> + + Updating a tuple in a base table of this materialized view is rapid but the + <command>REFRESH MATERIALIZED VIEW</command> command on this view takes a long time: + +<programlisting> +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) +</programlisting> +</para> + +<para> + On the other hand, after creating <acronym>IMMV</acronym> with the same view + definition as below: + +<programlisting> +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" +</programlisting> + + 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 + <command>REFRESH MATERIALIZED VIEW</command> command. + +<programlisting> +test=# UPDATE pgbench_accounts SET abalance = 1000 WHERE aid = 1; +UPDATE 1 +Time: 13.068 ms +</programlisting> + +</para> + +<para> + Appropriate indexes on <acronym>IMMV</acronym>s are necessary for + efficient <acronym>IVM</acronym> because it looks for tuples to be + updated in <acronym>IMMV</acronym>. If there are no indexes, it + will take a long time. +</para> + +<para> + Therefore, when <acronym>IMMV</acronym> 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. +</para> + +<para> + 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. +<programlisting> +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) +</programlisting> + +</para> + +<para> + <acronym>IVM</acronym> 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, <acronym>IVM</acronym> + 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, <acronym>IVM</acronym> is not effective and the cost of + maintenance can be larger than the <command>REFRESH MATERIALIZED VIEW</command> + command. In such situation, we can use <command>REFRESH MATERIALIZED VIEW</command> + and specify <literal>WITH NO DATA</literal> to disable immediate + maintenance before modifying a base table. After a base table modification, + execute the <command>REFRESH MATERIALIZED VIEW</command> (with <literal>WITH DATA</literal>) + command to refresh the view data and enable immediate maintenance. +</para> + +</sect2> + +<sect2 id="rules-ivm-support"> +<title>Supported View Definitions and Restrictions</title> + +<para> + Currently, we can create <acronym>IMMV</acronym>s using inner joins, and some + aggregates. However, several restrictions apply to the definition of IMMV. +</para> + +<sect3 id="rules-ivm-support-joins"> +<title>Joins</title> +<para> + Inner joins including self-join are supported. Outer joins are not supported. +</para> +</sect3> + +<sect3 id="rules-ivm-support-aggregates"> +<title>Aggregates</title> +<para> + Supported aggregate functions are <function>count</function>, <function>sum</function>, + <function>avg</function>, <function>min</function>, and <function>max</function>. + 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 <acronym>IMMV</acronym>. +</para> + +<para> + Note that for <function>min</function> or <function>max</function>, 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 <acronym>IMMV</acronym> containing + these functions. +</para> + +<para> + Also note that using <function>sum</function> or <function>avg</function> on + <type>real</type> (<type>float4</type>) type or <type>double precision</type> + (<type>float8</type>) type in <acronym>IMMV</acronym> is unsafe. This is + because aggregated values in <acronym>IMMV</acronym> can become different from + results calculated from base tables due to the limited precision of these types. + To avoid this problem, use the <type>numeric</type> type instead. +</para> + + <sect4 id="rules-ivm-restrictions-aggregates"> + <title>Restrictions on Aggregates</title> + <para> + There are the following restrictions: + <itemizedlist> + <listitem> + <para> + If we have a <literal>GROUP BY</literal> clause, expressions specified in + <literal>GROUP BY</literal> must appear in the target list. This is + how tuples to be updated in the <acronym>IMMV</acronym> are identified. + These attributes are used as scan keys for searching tuples in the + <acronym>IMMV</acronym>, so indexes on them are required for efficient + <acronym>IVM</acronym>. + </para> + </listitem> + + <listitem> + <para> + <literal>HAVING</literal> clause cannot be used. + </para> + </listitem> + </itemizedlist> + </para> + </sect4> +</sect3> + +<sect3 id="rules-ivm-general-restricitons"> +<title>Other General Restrictions</title> +<para> + There are other restrictions which generally apply to <acronym>IMMV</acronym>: + <itemizedlist> + <listitem> + <para> + Sub-queries cannot be used. + </para> + </listitem> + + <listitem> + <para> + CTEs cannot be used. + </para> + </listitem> + + <listitem> + <para> + Window functions cannot be used. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s must be based on simple base tables. It's not + supported to create them on top of views, materialized views, foreign tables, inhe. + </para> + </listitem> + + <listitem> + <para> + LIMIT and OFFSET clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s cannot contain system columns. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s cannot contain non-immutable functions. + </para> + </listitem> + + <listitem> + <para> + UNION/INTERSECT/EXCEPT clauses cannnot be used. + </para> + </listitem> + + <listitem> + <para> + DISTINCT ON clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + TABLESAMPLE parameter cannot be used. + </para> + </listitem> + + <listitem> + <para> + inheritance parent tables cannnot be used. + </para> + </listitem> + + <listitem> + <para> + VALUES clause cannnot be used. + </para> + </listitem> + + <listitem> + <para> + <literal>GROUPING SETS</literal> and <literal>FILTER</literal> clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + FOR UPDATE/SHARE cannot be used. + </para> + </listitem> + + <listitem> + <para> + targetlist cannot contain columns whose name start with <literal>__ivm_</literal>. + </para> + </listitem> + + <listitem> + <para> + targetlist cannot contain expressions which contain an aggregate in it. + </para> + </listitem> + + <listitem> + <para> + Logical replication is not supported, that is, even when a base table + at a publisher node is modified, <acronym>IMMV</acronym>s at subscriber + nodes are not updated. + </para> + </listitem> + + </itemizedlist> +</para> +</sect3> + +</sect2> + +<sect2 id="rules-ivm-distinct"> +<title><literal>DISTINCT</literal></title> + +<para> + <productname>PostgreSQL</productname> supports <acronym>IMMV</acronym> with + <literal>DISTINCT</literal>. For example, suppose a <acronym>IMMV</acronym> + defined with <literal>DISTINCT</literal> 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. +</para> + +<para> + Physically, an <acronym>IMMV</acronym> defined with <literal>DISTINCT</literal> + contains tuples after eliminating duplicates, and the multiplicity of each tuple + is stored in a hidden column named <literal>__ivm_count__</literal>. +</para> +</sect2> + +<sect2 id="rules-ivm-concurrent-transactions"> +<title>Concurrent Transactions</title> +<para> + Suppose an <acronym>IMMV</acronym> is defined on two base tables and each + table was modified in different a concurrent transaction simultaneously. + In the transaction which was committed first, <acronym>IMMV</acronym> 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, <literal>ExclusiveLock</literal> + is held on an <acronym>IMMV</acronym> immediately after a base table is + modified in <literal>READ COMMITTED</literal> mode to make sure that + the <acronym>IMMV</acronym> is updated in the latter transaction after + the former transaction is committed. In <literal>REPEATABLE READ</literal> + or <literal>SERIALIZABLE</literal> 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 + <acronym>IMMV</acronym> cannot be updated correctly in such situations. + However, as an exception if the view has only one base table and + <command>INSERT</command> is performed on the table, + the lock held on thew view is <literal>RowExclusiveLock</literal>. +</para> +</sect2> + +<sect2 id="rules-ivm-rls"> +<title>Row Level Security</title> +<para> + 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. +</para> +</sect2> + +</sect1> + <sect1 id="rules-update"> <title>Rules on <command>INSERT</command>, <command>UPDATE</command>, and <command>DELETE</command></title> diff --git a/doc/src/sgml/system-views.sgml b/doc/src/sgml/system-views.sgml index be90edd0e2..c909b2ab91 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 </para></entry> </row> + <row> + <entry role="catalog_table_entry"><para role="column_definition"> + <structfield>isimmv</structfield> <type>bool</type> + </para> + <para> + True if materialized view is incrementally maintainable + </para></entry> + </row> + <row> <entry role="catalog_table_entry"><para role="column_definition"> <structfield>definition</structfield> <type>text</type> -- 2.25.1 --Multipart=_Mon__4_Mar_2024_11_58_46_+0900_UaponF/qQhQrVCFt-- ^ permalink raw reply [nested|flat] 22+ messages in thread
* [PATCH v30 11/11] Add documentations about Incremental View Maintenance @ 2019-12-20 01:25 Yugo Nagata <[email protected]> 0 siblings, 0 replies; 22+ messages in thread From: Yugo Nagata @ 2019-12-20 01:25 UTC (permalink / raw) --- 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 880f717b10..f8df2951a8 100644 --- a/doc/src/sgml/catalogs.sgml +++ b/doc/src/sgml/catalogs.sgml @@ -2224,6 +2224,15 @@ SCRAM-SHA-256$<replaceable><iteration count></replaceable>:<replaceable>&l </para></entry> </row> + <row> + <entry role="catalog_table_entry"><para role="column_definition"> + <structfield>relisivm</structfield> <type>bool</type> + </para> + <para> + True if relation is incrementally maintainable materialized view + </para></entry> + </row> + <row> <entry role="catalog_table_entry"><para role="column_definition"> <structfield>relrewrite</structfield> <type>oid</type> 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 <refsynopsisdiv> <synopsis> -CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> +CREATE [ INCREMENTAL ] MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> [ (<replaceable>column_name</replaceable> [, ...] ) ] [ USING <replaceable class="parameter">method</replaceable> ] [ WITH ( <replaceable class="parameter">storage_parameter</replaceable> [= <replaceable class="parameter">value</replaceable>] [, ... ] ) ] @@ -60,6 +60,125 @@ CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> <title>Parameters</title> <variablelist> + <varlistentry> + <term><literal>INCREMENTAL</literal></term> + <listitem> + <para> + 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). + </para> + <para> + When <acronym>IMMV</acronym> is defined without using <command>WITH NO DATA</command>, + 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. + </para> + <para> + There are restrictions of query definitions allowed to use this + option. The following are supported in query definitions for IMMV: + <itemizedlist> + + <listitem> + <para> + Inner joins (including self-joins). + </para> + </listitem> + + <listitem> + <para> + Some built-in aggregate functions (count, sum, avg, min, max) without a HAVING + clause. + </para> + </listitem> + </itemizedlist> + + Unsupported queries with this option include the following: + + <itemizedlist> + <listitem> + <para> + Outer joins. + </para> + </listitem> + + <listitem> + <para> + Sub-queries. + </para> + </listitem> + + <listitem> + <para> + Aggregate functions other than built-in count, sum, avg, min and max. + </para> + </listitem> + <listitem> + <para> + Aggregate functions with a HAVING clause. + </para> + </listitem> + <listitem> + <para> + DISTINCT ON, WINDOW, VALUES, LIMIT and OFFSET clause. + </para> + </listitem> + </itemizedlist> + + Other restrictions include: + <itemizedlist> + + <listitem> + <para> + IMMVs must be based on simple base tables. It's not supported to + create them on top of views or materialized views. + </para> + </listitem> + + <listitem> + <para> + It is not supported to include system columns in an IMMV. + <programlisting> +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 + </programlisting> + </para> + </listitem> + + <listitem> + <para> + Non-immutable functions are not supported. + <programlisting> +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 + </programlisting> + </para> + </listitem> + + <listitem> + <para> + IMMVs do not support expressions that contains aggregates + </para> + </listitem> + + <listitem> + <para> + Logical replication does not support IMMVs. + </para> + </listitem> + + </itemizedlist> + + </para> + </listitem> + </varlistentry> + <varlistentry> <term><literal>IF NOT EXISTS</literal></term> <listitem> @@ -155,7 +274,8 @@ CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> 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 <command>REFRESH - MATERIALIZED VIEW</command> is used. + MATERIALIZED VIEW</command> is used. Also, if the view is IMMV, + triggers for maintaining the view are not created. </para> </listitem> </varlistentry> diff --git a/doc/src/sgml/ref/refresh_materialized_view.sgml b/doc/src/sgml/ref/refresh_materialized_view.sgml index 7a019162c3..dd894a2324 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 ] <replaceable class="parameter">name</ owner of the materialized view. The old contents are discarded. If <literal>WITH DATA</literal> 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 <literal>WITH NO DATA</literal> 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 <literal>WITH NO DATA</literal> 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. </para> <para> <literal>CONCURRENTLY</literal> and <literal>WITH NO DATA</literal> may not diff --git a/doc/src/sgml/rules.sgml b/doc/src/sgml/rules.sgml index 784c16e76e..149bb99b1c 100644 --- a/doc/src/sgml/rules.sgml +++ b/doc/src/sgml/rules.sgml @@ -1098,6 +1098,443 @@ SELECT word FROM words ORDER BY word <-> 'caterpiler' LIMIT 10; </sect1> +<sect1 id="rules-ivm"> +<title>Incremental View Maintenance</title> + +<indexterm zone="rules-ivm"> + <primary>incremental view maintenance</primary> +</indexterm> + +<indexterm zone="rules-ivm"> + <primary>materialized view</primary> + <secondary>incremental view maintenance</secondary> +</indexterm> + +<indexterm zone="rules-ivm"> + <primary>view</primary> + <secondary>incremental view maintenance</secondary> +</indexterm> + +<sect2 id="rules-ivm-overview"> +<title>Overview</title> + +<para> + Incremental View Maintenance (<acronym>IVM</acronym>) 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 + <command>REFRESH MATERIALIZED VIEW</command> does. <acronym>IVM</acronym> + can update materialized views more efficiently than recomputation when only + small parts of the view are changed. +</para> + +<para> + 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 <command>REFRESH + MATERIALIZED VIEW</command>, or periodically in background, and so on. + <productname>PostgreSQL</productname> currently implements only a kind of + immediate maintenance, in which materialized views are updated immediately + in AFTER triggers when a base table is modified. +</para> + +<para> + To create materialized views supporting <acronym>IVM</acronym>, use the + <command>CREATE INCREMENTAL MATERIALIZED VIEW</command>, for example: +<programlisting> +CREATE <emphasis>INCREMENTAL</emphasis> MATERIALIZED VIEW mymatview AS SELECT * FROM mytab; +</programlisting> + When a materialized view is created with the <literal>INCREMENTAL</literal> + 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 + (<acronym>IMMV</acronym>). +<programlisting> +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) +</programlisting> +</para> + +<para> + Some <acronym>IMMV</acronym>s have hidden columns which are added + automatically when a materialized view is created. Their name starts + with <literal>__ivm_</literal> and they contain information required + for maintaining the <acronym>IMMV</acronym>. Such columns are not visible + when the <acronym>IMMV</acronym> is accessed by <literal>SELECT *</literal> + but are visible if the column name is explicitly specified in the target + list. We can also see the hidden columns in <literal>\d</literal> + meta-commands of <command>psql</command> commands. +</para> + +<para> + In general, <acronym>IMMV</acronym>s allow faster updates of materialized + views at the price of slower updates to their base tables. Updates of + <acronym>IMMV</acronym> is slower because triggers will be invoked and the + view is updated in triggers per modification statement. +</para> + +<para> + For example, suppose a normal materialized view defined as below: + +<programlisting> +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 + +</programlisting> + + Updating a tuple in a base table of this materialized view is rapid but the + <command>REFRESH MATERIALIZED VIEW</command> command on this view takes a long time: + +<programlisting> +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) +</programlisting> +</para> + +<para> + On the other hand, after creating <acronym>IMMV</acronym> with the same view + definition as below: + +<programlisting> +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" +</programlisting> + + 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 + <command>REFRESH MATERIALIZED VIEW</command> command. + +<programlisting> +test=# UPDATE pgbench_accounts SET abalance = 1000 WHERE aid = 1; +UPDATE 1 +Time: 13.068 ms +</programlisting> + +</para> + +<para> + Appropriate indexes on <acronym>IMMV</acronym>s are necessary for + efficient <acronym>IVM</acronym> because it looks for tuples to be + updated in <acronym>IMMV</acronym>. If there are no indexes, it + will take a long time. +</para> + +<para> + Therefore, when <acronym>IMMV</acronym> 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. +</para> + +<para> + 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. +<programlisting> +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) +</programlisting> + +</para> + +<para> + <acronym>IVM</acronym> 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, <acronym>IVM</acronym> + 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, <acronym>IVM</acronym> is not effective and the cost of + maintenance can be larger than the <command>REFRESH MATERIALIZED VIEW</command> + command. In such situation, we can use <command>REFRESH MATERIALIZED VIEW</command> + and specify <literal>WITH NO DATA</literal> to disable immediate + maintenance before modifying a base table. After a base table modification, + execute the <command>REFRESH MATERIALIZED VIEW</command> (with <literal>WITH DATA</literal>) + command to refresh the view data and enable immediate maintenance. +</para> + +</sect2> + +<sect2 id="rules-ivm-support"> +<title>Supported View Definitions and Restrictions</title> + +<para> + Currently, we can create <acronym>IMMV</acronym>s using inner joins, and some + aggregates. However, several restrictions apply to the definition of IMMV. +</para> + +<sect3 id="rules-ivm-support-joins"> +<title>Joins</title> +<para> + Inner joins including self-join are supported. Outer joins are not supported. +</para> +</sect3> + +<sect3 id="rules-ivm-support-aggregates"> +<title>Aggregates</title> +<para> + Supported aggregate functions are <function>count</function>, <function>sum</function>, + <function>avg</function>, <function>min</function>, and <function>max</function>. + 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 <acronym>IMMV</acronym>. +</para> + +<para> + Note that for <function>min</function> or <function>max</function>, 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 <acronym>IMMV</acronym> containing + these functions. +</para> + +<para> + Also note that using <function>sum</function> or <function>avg</function> on + <type>real</type> (<type>float4</type>) type or <type>double precision</type> + (<type>float8</type>) type in <acronym>IMMV</acronym> is unsafe. This is + because aggregated values in <acronym>IMMV</acronym> can become different from + results calculated from base tables due to the limited precision of these types. + To avoid this problem, use the <type>numeric</type> type instead. +</para> + + <sect4 id="rules-ivm-restrictions-aggregates"> + <title>Restrictions on Aggregates</title> + <para> + There are the following restrictions: + <itemizedlist> + <listitem> + <para> + If we have a <literal>GROUP BY</literal> clause, expressions specified in + <literal>GROUP BY</literal> must appear in the target list. This is + how tuples to be updated in the <acronym>IMMV</acronym> are identified. + These attributes are used as scan keys for searching tuples in the + <acronym>IMMV</acronym>, so indexes on them are required for efficient + <acronym>IVM</acronym>. + </para> + </listitem> + + <listitem> + <para> + <literal>HAVING</literal> clause cannot be used. + </para> + </listitem> + </itemizedlist> + </para> + </sect4> +</sect3> + +<sect3 id="rules-ivm-general-restricitons"> +<title>Other General Restrictions</title> +<para> + There are other restrictions which generally apply to <acronym>IMMV</acronym>: + <itemizedlist> + <listitem> + <para> + Sub-queries cannot be used. + </para> + </listitem> + + <listitem> + <para> + CTEs cannot be used. + </para> + </listitem> + + <listitem> + <para> + Window functions cannot be used. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s must be based on simple base tables. It's not + supported to create them on top of views, materialized views, foreign tables, inhe. + </para> + </listitem> + + <listitem> + <para> + LIMIT and OFFSET clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s cannot contain system columns. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s cannot contain non-immutable functions. + </para> + </listitem> + + <listitem> + <para> + UNION/INTERSECT/EXCEPT clauses cannnot be used. + </para> + </listitem> + + <listitem> + <para> + DISTINCT ON clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + TABLESAMPLE parameter cannot be used. + </para> + </listitem> + + <listitem> + <para> + inheritance parent tables cannnot be used. + </para> + </listitem> + + <listitem> + <para> + VALUES clause cannnot be used. + </para> + </listitem> + + <listitem> + <para> + <literal>GROUPING SETS</literal> and <literal>FILTER</literal> clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + FOR UPDATE/SHARE cannot be used. + </para> + </listitem> + + <listitem> + <para> + targetlist cannot contain columns whose name start with <literal>__ivm_</literal>. + </para> + </listitem> + + <listitem> + <para> + targetlist cannot contain expressions which contain an aggregate in it. + </para> + </listitem> + + <listitem> + <para> + Logical replication is not supported, that is, even when a base table + at a publisher node is modified, <acronym>IMMV</acronym>s at subscriber + nodes are not updated. + </para> + </listitem> + + </itemizedlist> +</para> +</sect3> + +</sect2> + +<sect2 id="rules-ivm-distinct"> +<title><literal>DISTINCT</literal></title> + +<para> + <productname>PostgreSQL</productname> supports <acronym>IMMV</acronym> with + <literal>DISTINCT</literal>. For example, suppose a <acronym>IMMV</acronym> + defined with <literal>DISTINCT</literal> 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. +</para> + +<para> + Physically, an <acronym>IMMV</acronym> defined with <literal>DISTINCT</literal> + contains tuples after eliminating duplicates, and the multiplicity of each tuple + is stored in a hidden column named <literal>__ivm_count__</literal>. +</para> +</sect2> + +<sect2 id="rules-ivm-concurrent-transactions"> +<title>Concurrent Transactions</title> +<para> + Suppose an <acronym>IMMV</acronym> is defined on two base tables and each + table was modified in different a concurrent transaction simultaneously. + In the transaction which was committed first, <acronym>IMMV</acronym> 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, <literal>ExclusiveLock</literal> + is held on an <acronym>IMMV</acronym> immediately after a base table is + modified in <literal>READ COMMITTED</literal> mode to make sure that + the <acronym>IMMV</acronym> is updated in the latter transaction after + the former transaction is committed. In <literal>REPEATABLE READ</literal> + or <literal>SERIALIZABLE</literal> 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 + <acronym>IMMV</acronym> cannot be updated correctly in such situations. + However, as an exception if the view has only one base table and + <command>INSERT</command> is performed on the table, + the lock held on thew view is <literal>RowExclusiveLock</literal>. +</para> +</sect2> + +<sect2 id="rules-ivm-rls"> +<title>Row Level Security</title> +<para> + 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. +</para> +</sect2> + +</sect1> + <sect1 id="rules-update"> <title>Rules on <command>INSERT</command>, <command>UPDATE</command>, and <command>DELETE</command></title> diff --git a/doc/src/sgml/system-views.sgml b/doc/src/sgml/system-views.sgml index be90edd0e2..c909b2ab91 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 </para></entry> </row> + <row> + <entry role="catalog_table_entry"><para role="column_definition"> + <structfield>isimmv</structfield> <type>bool</type> + </para> + <para> + True if materialized view is incrementally maintainable + </para></entry> + </row> + <row> <entry role="catalog_table_entry"><para role="column_definition"> <structfield>definition</structfield> <type>text</type> -- 2.25.1 --Multipart=_Mon__4_Mar_2024_11_58_46_+0900_UaponF/qQhQrVCFt-- ^ permalink raw reply [nested|flat] 22+ messages in thread
* [PATCH v30 11/11] Add documentations about Incremental View Maintenance @ 2019-12-20 01:25 Yugo Nagata <[email protected]> 0 siblings, 0 replies; 22+ messages in thread From: Yugo Nagata @ 2019-12-20 01:25 UTC (permalink / raw) --- 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 880f717b10..f8df2951a8 100644 --- a/doc/src/sgml/catalogs.sgml +++ b/doc/src/sgml/catalogs.sgml @@ -2224,6 +2224,15 @@ SCRAM-SHA-256$<replaceable><iteration count></replaceable>:<replaceable>&l </para></entry> </row> + <row> + <entry role="catalog_table_entry"><para role="column_definition"> + <structfield>relisivm</structfield> <type>bool</type> + </para> + <para> + True if relation is incrementally maintainable materialized view + </para></entry> + </row> + <row> <entry role="catalog_table_entry"><para role="column_definition"> <structfield>relrewrite</structfield> <type>oid</type> 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 <refsynopsisdiv> <synopsis> -CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> +CREATE [ INCREMENTAL ] MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> [ (<replaceable>column_name</replaceable> [, ...] ) ] [ USING <replaceable class="parameter">method</replaceable> ] [ WITH ( <replaceable class="parameter">storage_parameter</replaceable> [= <replaceable class="parameter">value</replaceable>] [, ... ] ) ] @@ -60,6 +60,125 @@ CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> <title>Parameters</title> <variablelist> + <varlistentry> + <term><literal>INCREMENTAL</literal></term> + <listitem> + <para> + 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). + </para> + <para> + When <acronym>IMMV</acronym> is defined without using <command>WITH NO DATA</command>, + 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. + </para> + <para> + There are restrictions of query definitions allowed to use this + option. The following are supported in query definitions for IMMV: + <itemizedlist> + + <listitem> + <para> + Inner joins (including self-joins). + </para> + </listitem> + + <listitem> + <para> + Some built-in aggregate functions (count, sum, avg, min, max) without a HAVING + clause. + </para> + </listitem> + </itemizedlist> + + Unsupported queries with this option include the following: + + <itemizedlist> + <listitem> + <para> + Outer joins. + </para> + </listitem> + + <listitem> + <para> + Sub-queries. + </para> + </listitem> + + <listitem> + <para> + Aggregate functions other than built-in count, sum, avg, min and max. + </para> + </listitem> + <listitem> + <para> + Aggregate functions with a HAVING clause. + </para> + </listitem> + <listitem> + <para> + DISTINCT ON, WINDOW, VALUES, LIMIT and OFFSET clause. + </para> + </listitem> + </itemizedlist> + + Other restrictions include: + <itemizedlist> + + <listitem> + <para> + IMMVs must be based on simple base tables. It's not supported to + create them on top of views or materialized views. + </para> + </listitem> + + <listitem> + <para> + It is not supported to include system columns in an IMMV. + <programlisting> +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 + </programlisting> + </para> + </listitem> + + <listitem> + <para> + Non-immutable functions are not supported. + <programlisting> +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 + </programlisting> + </para> + </listitem> + + <listitem> + <para> + IMMVs do not support expressions that contains aggregates + </para> + </listitem> + + <listitem> + <para> + Logical replication does not support IMMVs. + </para> + </listitem> + + </itemizedlist> + + </para> + </listitem> + </varlistentry> + <varlistentry> <term><literal>IF NOT EXISTS</literal></term> <listitem> @@ -155,7 +274,8 @@ CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> 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 <command>REFRESH - MATERIALIZED VIEW</command> is used. + MATERIALIZED VIEW</command> is used. Also, if the view is IMMV, + triggers for maintaining the view are not created. </para> </listitem> </varlistentry> diff --git a/doc/src/sgml/ref/refresh_materialized_view.sgml b/doc/src/sgml/ref/refresh_materialized_view.sgml index 7a019162c3..dd894a2324 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 ] <replaceable class="parameter">name</ owner of the materialized view. The old contents are discarded. If <literal>WITH DATA</literal> 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 <literal>WITH NO DATA</literal> 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 <literal>WITH NO DATA</literal> 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. </para> <para> <literal>CONCURRENTLY</literal> and <literal>WITH NO DATA</literal> may not diff --git a/doc/src/sgml/rules.sgml b/doc/src/sgml/rules.sgml index 784c16e76e..149bb99b1c 100644 --- a/doc/src/sgml/rules.sgml +++ b/doc/src/sgml/rules.sgml @@ -1098,6 +1098,443 @@ SELECT word FROM words ORDER BY word <-> 'caterpiler' LIMIT 10; </sect1> +<sect1 id="rules-ivm"> +<title>Incremental View Maintenance</title> + +<indexterm zone="rules-ivm"> + <primary>incremental view maintenance</primary> +</indexterm> + +<indexterm zone="rules-ivm"> + <primary>materialized view</primary> + <secondary>incremental view maintenance</secondary> +</indexterm> + +<indexterm zone="rules-ivm"> + <primary>view</primary> + <secondary>incremental view maintenance</secondary> +</indexterm> + +<sect2 id="rules-ivm-overview"> +<title>Overview</title> + +<para> + Incremental View Maintenance (<acronym>IVM</acronym>) 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 + <command>REFRESH MATERIALIZED VIEW</command> does. <acronym>IVM</acronym> + can update materialized views more efficiently than recomputation when only + small parts of the view are changed. +</para> + +<para> + 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 <command>REFRESH + MATERIALIZED VIEW</command>, or periodically in background, and so on. + <productname>PostgreSQL</productname> currently implements only a kind of + immediate maintenance, in which materialized views are updated immediately + in AFTER triggers when a base table is modified. +</para> + +<para> + To create materialized views supporting <acronym>IVM</acronym>, use the + <command>CREATE INCREMENTAL MATERIALIZED VIEW</command>, for example: +<programlisting> +CREATE <emphasis>INCREMENTAL</emphasis> MATERIALIZED VIEW mymatview AS SELECT * FROM mytab; +</programlisting> + When a materialized view is created with the <literal>INCREMENTAL</literal> + 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 + (<acronym>IMMV</acronym>). +<programlisting> +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) +</programlisting> +</para> + +<para> + Some <acronym>IMMV</acronym>s have hidden columns which are added + automatically when a materialized view is created. Their name starts + with <literal>__ivm_</literal> and they contain information required + for maintaining the <acronym>IMMV</acronym>. Such columns are not visible + when the <acronym>IMMV</acronym> is accessed by <literal>SELECT *</literal> + but are visible if the column name is explicitly specified in the target + list. We can also see the hidden columns in <literal>\d</literal> + meta-commands of <command>psql</command> commands. +</para> + +<para> + In general, <acronym>IMMV</acronym>s allow faster updates of materialized + views at the price of slower updates to their base tables. Updates of + <acronym>IMMV</acronym> is slower because triggers will be invoked and the + view is updated in triggers per modification statement. +</para> + +<para> + For example, suppose a normal materialized view defined as below: + +<programlisting> +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 + +</programlisting> + + Updating a tuple in a base table of this materialized view is rapid but the + <command>REFRESH MATERIALIZED VIEW</command> command on this view takes a long time: + +<programlisting> +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) +</programlisting> +</para> + +<para> + On the other hand, after creating <acronym>IMMV</acronym> with the same view + definition as below: + +<programlisting> +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" +</programlisting> + + 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 + <command>REFRESH MATERIALIZED VIEW</command> command. + +<programlisting> +test=# UPDATE pgbench_accounts SET abalance = 1000 WHERE aid = 1; +UPDATE 1 +Time: 13.068 ms +</programlisting> + +</para> + +<para> + Appropriate indexes on <acronym>IMMV</acronym>s are necessary for + efficient <acronym>IVM</acronym> because it looks for tuples to be + updated in <acronym>IMMV</acronym>. If there are no indexes, it + will take a long time. +</para> + +<para> + Therefore, when <acronym>IMMV</acronym> 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. +</para> + +<para> + 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. +<programlisting> +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) +</programlisting> + +</para> + +<para> + <acronym>IVM</acronym> 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, <acronym>IVM</acronym> + 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, <acronym>IVM</acronym> is not effective and the cost of + maintenance can be larger than the <command>REFRESH MATERIALIZED VIEW</command> + command. In such situation, we can use <command>REFRESH MATERIALIZED VIEW</command> + and specify <literal>WITH NO DATA</literal> to disable immediate + maintenance before modifying a base table. After a base table modification, + execute the <command>REFRESH MATERIALIZED VIEW</command> (with <literal>WITH DATA</literal>) + command to refresh the view data and enable immediate maintenance. +</para> + +</sect2> + +<sect2 id="rules-ivm-support"> +<title>Supported View Definitions and Restrictions</title> + +<para> + Currently, we can create <acronym>IMMV</acronym>s using inner joins, and some + aggregates. However, several restrictions apply to the definition of IMMV. +</para> + +<sect3 id="rules-ivm-support-joins"> +<title>Joins</title> +<para> + Inner joins including self-join are supported. Outer joins are not supported. +</para> +</sect3> + +<sect3 id="rules-ivm-support-aggregates"> +<title>Aggregates</title> +<para> + Supported aggregate functions are <function>count</function>, <function>sum</function>, + <function>avg</function>, <function>min</function>, and <function>max</function>. + 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 <acronym>IMMV</acronym>. +</para> + +<para> + Note that for <function>min</function> or <function>max</function>, 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 <acronym>IMMV</acronym> containing + these functions. +</para> + +<para> + Also note that using <function>sum</function> or <function>avg</function> on + <type>real</type> (<type>float4</type>) type or <type>double precision</type> + (<type>float8</type>) type in <acronym>IMMV</acronym> is unsafe. This is + because aggregated values in <acronym>IMMV</acronym> can become different from + results calculated from base tables due to the limited precision of these types. + To avoid this problem, use the <type>numeric</type> type instead. +</para> + + <sect4 id="rules-ivm-restrictions-aggregates"> + <title>Restrictions on Aggregates</title> + <para> + There are the following restrictions: + <itemizedlist> + <listitem> + <para> + If we have a <literal>GROUP BY</literal> clause, expressions specified in + <literal>GROUP BY</literal> must appear in the target list. This is + how tuples to be updated in the <acronym>IMMV</acronym> are identified. + These attributes are used as scan keys for searching tuples in the + <acronym>IMMV</acronym>, so indexes on them are required for efficient + <acronym>IVM</acronym>. + </para> + </listitem> + + <listitem> + <para> + <literal>HAVING</literal> clause cannot be used. + </para> + </listitem> + </itemizedlist> + </para> + </sect4> +</sect3> + +<sect3 id="rules-ivm-general-restricitons"> +<title>Other General Restrictions</title> +<para> + There are other restrictions which generally apply to <acronym>IMMV</acronym>: + <itemizedlist> + <listitem> + <para> + Sub-queries cannot be used. + </para> + </listitem> + + <listitem> + <para> + CTEs cannot be used. + </para> + </listitem> + + <listitem> + <para> + Window functions cannot be used. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s must be based on simple base tables. It's not + supported to create them on top of views, materialized views, foreign tables, inhe. + </para> + </listitem> + + <listitem> + <para> + LIMIT and OFFSET clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s cannot contain system columns. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s cannot contain non-immutable functions. + </para> + </listitem> + + <listitem> + <para> + UNION/INTERSECT/EXCEPT clauses cannnot be used. + </para> + </listitem> + + <listitem> + <para> + DISTINCT ON clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + TABLESAMPLE parameter cannot be used. + </para> + </listitem> + + <listitem> + <para> + inheritance parent tables cannnot be used. + </para> + </listitem> + + <listitem> + <para> + VALUES clause cannnot be used. + </para> + </listitem> + + <listitem> + <para> + <literal>GROUPING SETS</literal> and <literal>FILTER</literal> clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + FOR UPDATE/SHARE cannot be used. + </para> + </listitem> + + <listitem> + <para> + targetlist cannot contain columns whose name start with <literal>__ivm_</literal>. + </para> + </listitem> + + <listitem> + <para> + targetlist cannot contain expressions which contain an aggregate in it. + </para> + </listitem> + + <listitem> + <para> + Logical replication is not supported, that is, even when a base table + at a publisher node is modified, <acronym>IMMV</acronym>s at subscriber + nodes are not updated. + </para> + </listitem> + + </itemizedlist> +</para> +</sect3> + +</sect2> + +<sect2 id="rules-ivm-distinct"> +<title><literal>DISTINCT</literal></title> + +<para> + <productname>PostgreSQL</productname> supports <acronym>IMMV</acronym> with + <literal>DISTINCT</literal>. For example, suppose a <acronym>IMMV</acronym> + defined with <literal>DISTINCT</literal> 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. +</para> + +<para> + Physically, an <acronym>IMMV</acronym> defined with <literal>DISTINCT</literal> + contains tuples after eliminating duplicates, and the multiplicity of each tuple + is stored in a hidden column named <literal>__ivm_count__</literal>. +</para> +</sect2> + +<sect2 id="rules-ivm-concurrent-transactions"> +<title>Concurrent Transactions</title> +<para> + Suppose an <acronym>IMMV</acronym> is defined on two base tables and each + table was modified in different a concurrent transaction simultaneously. + In the transaction which was committed first, <acronym>IMMV</acronym> 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, <literal>ExclusiveLock</literal> + is held on an <acronym>IMMV</acronym> immediately after a base table is + modified in <literal>READ COMMITTED</literal> mode to make sure that + the <acronym>IMMV</acronym> is updated in the latter transaction after + the former transaction is committed. In <literal>REPEATABLE READ</literal> + or <literal>SERIALIZABLE</literal> 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 + <acronym>IMMV</acronym> cannot be updated correctly in such situations. + However, as an exception if the view has only one base table and + <command>INSERT</command> is performed on the table, + the lock held on thew view is <literal>RowExclusiveLock</literal>. +</para> +</sect2> + +<sect2 id="rules-ivm-rls"> +<title>Row Level Security</title> +<para> + 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. +</para> +</sect2> + +</sect1> + <sect1 id="rules-update"> <title>Rules on <command>INSERT</command>, <command>UPDATE</command>, and <command>DELETE</command></title> diff --git a/doc/src/sgml/system-views.sgml b/doc/src/sgml/system-views.sgml index be90edd0e2..c909b2ab91 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 </para></entry> </row> + <row> + <entry role="catalog_table_entry"><para role="column_definition"> + <structfield>isimmv</structfield> <type>bool</type> + </para> + <para> + True if materialized view is incrementally maintainable + </para></entry> + </row> + <row> <entry role="catalog_table_entry"><para role="column_definition"> <structfield>definition</structfield> <type>text</type> -- 2.25.1 --Multipart=_Mon__4_Mar_2024_11_58_46_+0900_UaponF/qQhQrVCFt-- ^ permalink raw reply [nested|flat] 22+ messages in thread
* [PATCH v31 11/11] Add documentations about Incremental View Maintenance @ 2019-12-20 01:25 Yugo Nagata <[email protected]> 0 siblings, 0 replies; 22+ messages in thread From: Yugo Nagata @ 2019-12-20 01:25 UTC (permalink / raw) --- 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 096ddab481..d4255f1015 100644 --- a/doc/src/sgml/catalogs.sgml +++ b/doc/src/sgml/catalogs.sgml @@ -2231,6 +2231,15 @@ SCRAM-SHA-256$<replaceable><iteration count></replaceable>:<replaceable>&l </para></entry> </row> + <row> + <entry role="catalog_table_entry"><para role="column_definition"> + <structfield>relisivm</structfield> <type>bool</type> + </para> + <para> + True if relation is incrementally maintainable materialized view + </para></entry> + </row> + <row> <entry role="catalog_table_entry"><para role="column_definition"> <structfield>relrewrite</structfield> <type>oid</type> 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 <refsynopsisdiv> <synopsis> -CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> +CREATE [ INCREMENTAL ] MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> [ (<replaceable>column_name</replaceable> [, ...] ) ] [ USING <replaceable class="parameter">method</replaceable> ] [ WITH ( <replaceable class="parameter">storage_parameter</replaceable> [= <replaceable class="parameter">value</replaceable>] [, ... ] ) ] @@ -60,6 +60,125 @@ CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> <title>Parameters</title> <variablelist> + <varlistentry> + <term><literal>INCREMENTAL</literal></term> + <listitem> + <para> + 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). + </para> + <para> + When <acronym>IMMV</acronym> is defined without using <command>WITH NO DATA</command>, + 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. + </para> + <para> + There are restrictions of query definitions allowed to use this + option. The following are supported in query definitions for IMMV: + <itemizedlist> + + <listitem> + <para> + Inner joins (including self-joins). + </para> + </listitem> + + <listitem> + <para> + Some built-in aggregate functions (count, sum, avg, min, max) without a HAVING + clause. + </para> + </listitem> + </itemizedlist> + + Unsupported queries with this option include the following: + + <itemizedlist> + <listitem> + <para> + Outer joins. + </para> + </listitem> + + <listitem> + <para> + Sub-queries. + </para> + </listitem> + + <listitem> + <para> + Aggregate functions other than built-in count, sum, avg, min and max. + </para> + </listitem> + <listitem> + <para> + Aggregate functions with a HAVING clause. + </para> + </listitem> + <listitem> + <para> + DISTINCT ON, WINDOW, VALUES, LIMIT and OFFSET clause. + </para> + </listitem> + </itemizedlist> + + Other restrictions include: + <itemizedlist> + + <listitem> + <para> + IMMVs must be based on simple base tables. It's not supported to + create them on top of views or materialized views. + </para> + </listitem> + + <listitem> + <para> + It is not supported to include system columns in an IMMV. + <programlisting> +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 + </programlisting> + </para> + </listitem> + + <listitem> + <para> + Non-immutable functions are not supported. + <programlisting> +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 + </programlisting> + </para> + </listitem> + + <listitem> + <para> + IMMVs do not support expressions that contains aggregates + </para> + </listitem> + + <listitem> + <para> + Logical replication does not support IMMVs. + </para> + </listitem> + + </itemizedlist> + + </para> + </listitem> + </varlistentry> + <varlistentry> <term><literal>IF NOT EXISTS</literal></term> <listitem> @@ -155,7 +274,8 @@ CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> 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 <command>REFRESH - MATERIALIZED VIEW</command> is used. + MATERIALIZED VIEW</command> is used. Also, if the view is IMMV, + triggers for maintaining the view are not created. </para> </listitem> </varlistentry> diff --git a/doc/src/sgml/ref/refresh_materialized_view.sgml b/doc/src/sgml/ref/refresh_materialized_view.sgml index 8ed43ade80..a4d729bdf0 100644 --- a/doc/src/sgml/ref/refresh_materialized_view.sgml +++ b/doc/src/sgml/ref/refresh_materialized_view.sgml @@ -36,9 +36,13 @@ REFRESH MATERIALIZED VIEW [ CONCURRENTLY ] <replaceable class="parameter">name</ privilege on the materialized view. The old contents are discarded. If <literal>WITH DATA</literal> 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 <literal>WITH NO DATA</literal> 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 <literal>WITH NO DATA</literal> 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. </para> <para> <literal>CONCURRENTLY</literal> and <literal>WITH NO DATA</literal> may not diff --git a/doc/src/sgml/rules.sgml b/doc/src/sgml/rules.sgml index 7a928bd7b9..73597ea7a5 100644 --- a/doc/src/sgml/rules.sgml +++ b/doc/src/sgml/rules.sgml @@ -1100,6 +1100,443 @@ SELECT word FROM words ORDER BY word <-> 'caterpiler' LIMIT 10; </sect1> +<sect1 id="rules-ivm"> +<title>Incremental View Maintenance</title> + +<indexterm zone="rules-ivm"> + <primary>incremental view maintenance</primary> +</indexterm> + +<indexterm zone="rules-ivm"> + <primary>materialized view</primary> + <secondary>incremental view maintenance</secondary> +</indexterm> + +<indexterm zone="rules-ivm"> + <primary>view</primary> + <secondary>incremental view maintenance</secondary> +</indexterm> + +<sect2 id="rules-ivm-overview"> +<title>Overview</title> + +<para> + Incremental View Maintenance (<acronym>IVM</acronym>) 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 + <command>REFRESH MATERIALIZED VIEW</command> does. <acronym>IVM</acronym> + can update materialized views more efficiently than recomputation when only + small parts of the view are changed. +</para> + +<para> + 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 <command>REFRESH + MATERIALIZED VIEW</command>, or periodically in background, and so on. + <productname>PostgreSQL</productname> currently implements only a kind of + immediate maintenance, in which materialized views are updated immediately + in AFTER triggers when a base table is modified. +</para> + +<para> + To create materialized views supporting <acronym>IVM</acronym>, use the + <command>CREATE INCREMENTAL MATERIALIZED VIEW</command>, for example: +<programlisting> +CREATE <emphasis>INCREMENTAL</emphasis> MATERIALIZED VIEW mymatview AS SELECT * FROM mytab; +</programlisting> + When a materialized view is created with the <literal>INCREMENTAL</literal> + 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 + (<acronym>IMMV</acronym>). +<programlisting> +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) +</programlisting> +</para> + +<para> + Some <acronym>IMMV</acronym>s have hidden columns which are added + automatically when a materialized view is created. Their name starts + with <literal>__ivm_</literal> and they contain information required + for maintaining the <acronym>IMMV</acronym>. Such columns are not visible + when the <acronym>IMMV</acronym> is accessed by <literal>SELECT *</literal> + but are visible if the column name is explicitly specified in the target + list. We can also see the hidden columns in <literal>\d</literal> + meta-commands of <command>psql</command> commands. +</para> + +<para> + In general, <acronym>IMMV</acronym>s allow faster updates of materialized + views at the price of slower updates to their base tables. Updates of + <acronym>IMMV</acronym> is slower because triggers will be invoked and the + view is updated in triggers per modification statement. +</para> + +<para> + For example, suppose a normal materialized view defined as below: + +<programlisting> +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 + +</programlisting> + + Updating a tuple in a base table of this materialized view is rapid but the + <command>REFRESH MATERIALIZED VIEW</command> command on this view takes a long time: + +<programlisting> +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) +</programlisting> +</para> + +<para> + On the other hand, after creating <acronym>IMMV</acronym> with the same view + definition as below: + +<programlisting> +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" +</programlisting> + + 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 + <command>REFRESH MATERIALIZED VIEW</command> command. + +<programlisting> +test=# UPDATE pgbench_accounts SET abalance = 1000 WHERE aid = 1; +UPDATE 1 +Time: 13.068 ms +</programlisting> + +</para> + +<para> + Appropriate indexes on <acronym>IMMV</acronym>s are necessary for + efficient <acronym>IVM</acronym> because it looks for tuples to be + updated in <acronym>IMMV</acronym>. If there are no indexes, it + will take a long time. +</para> + +<para> + Therefore, when <acronym>IMMV</acronym> 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. +</para> + +<para> + 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. +<programlisting> +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) +</programlisting> + +</para> + +<para> + <acronym>IVM</acronym> 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, <acronym>IVM</acronym> + 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, <acronym>IVM</acronym> is not effective and the cost of + maintenance can be larger than the <command>REFRESH MATERIALIZED VIEW</command> + command. In such situation, we can use <command>REFRESH MATERIALIZED VIEW</command> + and specify <literal>WITH NO DATA</literal> to disable immediate + maintenance before modifying a base table. After a base table modification, + execute the <command>REFRESH MATERIALIZED VIEW</command> (with <literal>WITH DATA</literal>) + command to refresh the view data and enable immediate maintenance. +</para> + +</sect2> + +<sect2 id="rules-ivm-support"> +<title>Supported View Definitions and Restrictions</title> + +<para> + Currently, we can create <acronym>IMMV</acronym>s using inner joins, and some + aggregates. However, several restrictions apply to the definition of IMMV. +</para> + +<sect3 id="rules-ivm-support-joins"> +<title>Joins</title> +<para> + Inner joins including self-join are supported. Outer joins are not supported. +</para> +</sect3> + +<sect3 id="rules-ivm-support-aggregates"> +<title>Aggregates</title> +<para> + Supported aggregate functions are <function>count</function>, <function>sum</function>, + <function>avg</function>, <function>min</function>, and <function>max</function>. + 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 <acronym>IMMV</acronym>. +</para> + +<para> + Note that for <function>min</function> or <function>max</function>, 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 <acronym>IMMV</acronym> containing + these functions. +</para> + +<para> + Also note that using <function>sum</function> or <function>avg</function> on + <type>real</type> (<type>float4</type>) type or <type>double precision</type> + (<type>float8</type>) type in <acronym>IMMV</acronym> is unsafe. This is + because aggregated values in <acronym>IMMV</acronym> can become different from + results calculated from base tables due to the limited precision of these types. + To avoid this problem, use the <type>numeric</type> type instead. +</para> + + <sect4 id="rules-ivm-restrictions-aggregates"> + <title>Restrictions on Aggregates</title> + <para> + There are the following restrictions: + <itemizedlist> + <listitem> + <para> + If we have a <literal>GROUP BY</literal> clause, expressions specified in + <literal>GROUP BY</literal> must appear in the target list. This is + how tuples to be updated in the <acronym>IMMV</acronym> are identified. + These attributes are used as scan keys for searching tuples in the + <acronym>IMMV</acronym>, so indexes on them are required for efficient + <acronym>IVM</acronym>. + </para> + </listitem> + + <listitem> + <para> + <literal>HAVING</literal> clause cannot be used. + </para> + </listitem> + </itemizedlist> + </para> + </sect4> +</sect3> + +<sect3 id="rules-ivm-general-restricitons"> +<title>Other General Restrictions</title> +<para> + There are other restrictions which generally apply to <acronym>IMMV</acronym>: + <itemizedlist> + <listitem> + <para> + Sub-queries cannot be used. + </para> + </listitem> + + <listitem> + <para> + CTEs cannot be used. + </para> + </listitem> + + <listitem> + <para> + Window functions cannot be used. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s must be based on simple base tables. It's not + supported to create them on top of views, materialized views, foreign tables, inhe. + </para> + </listitem> + + <listitem> + <para> + LIMIT and OFFSET clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s cannot contain system columns. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s cannot contain non-immutable functions. + </para> + </listitem> + + <listitem> + <para> + UNION/INTERSECT/EXCEPT clauses cannnot be used. + </para> + </listitem> + + <listitem> + <para> + DISTINCT ON clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + TABLESAMPLE parameter cannot be used. + </para> + </listitem> + + <listitem> + <para> + inheritance parent tables cannnot be used. + </para> + </listitem> + + <listitem> + <para> + VALUES clause cannnot be used. + </para> + </listitem> + + <listitem> + <para> + <literal>GROUPING SETS</literal> and <literal>FILTER</literal> clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + FOR UPDATE/SHARE cannot be used. + </para> + </listitem> + + <listitem> + <para> + targetlist cannot contain columns whose name start with <literal>__ivm_</literal>. + </para> + </listitem> + + <listitem> + <para> + targetlist cannot contain expressions which contain an aggregate in it. + </para> + </listitem> + + <listitem> + <para> + Logical replication is not supported, that is, even when a base table + at a publisher node is modified, <acronym>IMMV</acronym>s at subscriber + nodes are not updated. + </para> + </listitem> + + </itemizedlist> +</para> +</sect3> + +</sect2> + +<sect2 id="rules-ivm-distinct"> +<title><literal>DISTINCT</literal></title> + +<para> + <productname>PostgreSQL</productname> supports <acronym>IMMV</acronym> with + <literal>DISTINCT</literal>. For example, suppose a <acronym>IMMV</acronym> + defined with <literal>DISTINCT</literal> 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. +</para> + +<para> + Physically, an <acronym>IMMV</acronym> defined with <literal>DISTINCT</literal> + contains tuples after eliminating duplicates, and the multiplicity of each tuple + is stored in a hidden column named <literal>__ivm_count__</literal>. +</para> +</sect2> + +<sect2 id="rules-ivm-concurrent-transactions"> +<title>Concurrent Transactions</title> +<para> + Suppose an <acronym>IMMV</acronym> is defined on two base tables and each + table was modified in different a concurrent transaction simultaneously. + In the transaction which was committed first, <acronym>IMMV</acronym> 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, <literal>ExclusiveLock</literal> + is held on an <acronym>IMMV</acronym> immediately after a base table is + modified in <literal>READ COMMITTED</literal> mode to make sure that + the <acronym>IMMV</acronym> is updated in the latter transaction after + the former transaction is committed. In <literal>REPEATABLE READ</literal> + or <literal>SERIALIZABLE</literal> 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 + <acronym>IMMV</acronym> cannot be updated correctly in such situations. + However, as an exception if the view has only one base table and + <command>INSERT</command> is performed on the table, + the lock held on thew view is <literal>RowExclusiveLock</literal>. +</para> +</sect2> + +<sect2 id="rules-ivm-rls"> +<title>Row Level Security</title> +<para> + 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. +</para> +</sect2> + +</sect1> + <sect1 id="rules-update"> <title>Rules on <command>INSERT</command>, <command>UPDATE</command>, and <command>DELETE</command></title> diff --git a/doc/src/sgml/system-views.sgml b/doc/src/sgml/system-views.sgml index 3c8dca8ca3..da22606213 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 </para></entry> </row> + <row> + <entry role="catalog_table_entry"><para role="column_definition"> + <structfield>isimmv</structfield> <type>bool</type> + </para> + <para> + True if materialized view is incrementally maintainable + </para></entry> + </row> + <row> <entry role="catalog_table_entry"><para role="column_definition"> <structfield>definition</structfield> <type>text</type> -- 2.25.1 --Multipart=_Fri__29_Mar_2024_23_47_00_+0900_KGpmmDOIs1266Ib1-- ^ permalink raw reply [nested|flat] 22+ messages in thread
* [PATCH v32 11/11] Add documentations about Incremental View Maintenance @ 2019-12-20 01:25 Yugo Nagata <[email protected]> 0 siblings, 0 replies; 22+ messages in thread From: Yugo Nagata @ 2019-12-20 01:25 UTC (permalink / raw) --- 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 096ddab481..d4255f1015 100644 --- a/doc/src/sgml/catalogs.sgml +++ b/doc/src/sgml/catalogs.sgml @@ -2231,6 +2231,15 @@ SCRAM-SHA-256$<replaceable><iteration count></replaceable>:<replaceable>&l </para></entry> </row> + <row> + <entry role="catalog_table_entry"><para role="column_definition"> + <structfield>relisivm</structfield> <type>bool</type> + </para> + <para> + True if relation is incrementally maintainable materialized view + </para></entry> + </row> + <row> <entry role="catalog_table_entry"><para role="column_definition"> <structfield>relrewrite</structfield> <type>oid</type> 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 <refsynopsisdiv> <synopsis> -CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> +CREATE [ INCREMENTAL ] MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> [ (<replaceable>column_name</replaceable> [, ...] ) ] [ USING <replaceable class="parameter">method</replaceable> ] [ WITH ( <replaceable class="parameter">storage_parameter</replaceable> [= <replaceable class="parameter">value</replaceable>] [, ... ] ) ] @@ -60,6 +60,125 @@ CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> <title>Parameters</title> <variablelist> + <varlistentry> + <term><literal>INCREMENTAL</literal></term> + <listitem> + <para> + 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). + </para> + <para> + When <acronym>IMMV</acronym> is defined without using <command>WITH NO DATA</command>, + 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. + </para> + <para> + There are restrictions of query definitions allowed to use this + option. The following are supported in query definitions for IMMV: + <itemizedlist> + + <listitem> + <para> + Inner joins (including self-joins). + </para> + </listitem> + + <listitem> + <para> + Some built-in aggregate functions (count, sum, avg, min, max) without a HAVING + clause. + </para> + </listitem> + </itemizedlist> + + Unsupported queries with this option include the following: + + <itemizedlist> + <listitem> + <para> + Outer joins. + </para> + </listitem> + + <listitem> + <para> + Sub-queries. + </para> + </listitem> + + <listitem> + <para> + Aggregate functions other than built-in count, sum, avg, min and max. + </para> + </listitem> + <listitem> + <para> + Aggregate functions with a HAVING clause. + </para> + </listitem> + <listitem> + <para> + DISTINCT ON, WINDOW, VALUES, LIMIT and OFFSET clause. + </para> + </listitem> + </itemizedlist> + + Other restrictions include: + <itemizedlist> + + <listitem> + <para> + IMMVs must be based on simple base tables. It's not supported to + create them on top of views or materialized views. + </para> + </listitem> + + <listitem> + <para> + It is not supported to include system columns in an IMMV. + <programlisting> +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 + </programlisting> + </para> + </listitem> + + <listitem> + <para> + Non-immutable functions are not supported. + <programlisting> +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 + </programlisting> + </para> + </listitem> + + <listitem> + <para> + IMMVs do not support expressions that contains aggregates + </para> + </listitem> + + <listitem> + <para> + Logical replication does not support IMMVs. + </para> + </listitem> + + </itemizedlist> + + </para> + </listitem> + </varlistentry> + <varlistentry> <term><literal>IF NOT EXISTS</literal></term> <listitem> @@ -155,7 +274,8 @@ CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> 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 <command>REFRESH - MATERIALIZED VIEW</command> is used. + MATERIALIZED VIEW</command> is used. Also, if the view is IMMV, + triggers for maintaining the view are not created. </para> </listitem> </varlistentry> diff --git a/doc/src/sgml/ref/refresh_materialized_view.sgml b/doc/src/sgml/ref/refresh_materialized_view.sgml index 8ed43ade80..a4d729bdf0 100644 --- a/doc/src/sgml/ref/refresh_materialized_view.sgml +++ b/doc/src/sgml/ref/refresh_materialized_view.sgml @@ -36,9 +36,13 @@ REFRESH MATERIALIZED VIEW [ CONCURRENTLY ] <replaceable class="parameter">name</ privilege on the materialized view. The old contents are discarded. If <literal>WITH DATA</literal> 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 <literal>WITH NO DATA</literal> 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 <literal>WITH NO DATA</literal> 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. </para> <para> <literal>CONCURRENTLY</literal> and <literal>WITH NO DATA</literal> may not diff --git a/doc/src/sgml/rules.sgml b/doc/src/sgml/rules.sgml index 7a928bd7b9..73597ea7a5 100644 --- a/doc/src/sgml/rules.sgml +++ b/doc/src/sgml/rules.sgml @@ -1100,6 +1100,443 @@ SELECT word FROM words ORDER BY word <-> 'caterpiler' LIMIT 10; </sect1> +<sect1 id="rules-ivm"> +<title>Incremental View Maintenance</title> + +<indexterm zone="rules-ivm"> + <primary>incremental view maintenance</primary> +</indexterm> + +<indexterm zone="rules-ivm"> + <primary>materialized view</primary> + <secondary>incremental view maintenance</secondary> +</indexterm> + +<indexterm zone="rules-ivm"> + <primary>view</primary> + <secondary>incremental view maintenance</secondary> +</indexterm> + +<sect2 id="rules-ivm-overview"> +<title>Overview</title> + +<para> + Incremental View Maintenance (<acronym>IVM</acronym>) 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 + <command>REFRESH MATERIALIZED VIEW</command> does. <acronym>IVM</acronym> + can update materialized views more efficiently than recomputation when only + small parts of the view are changed. +</para> + +<para> + 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 <command>REFRESH + MATERIALIZED VIEW</command>, or periodically in background, and so on. + <productname>PostgreSQL</productname> currently implements only a kind of + immediate maintenance, in which materialized views are updated immediately + in AFTER triggers when a base table is modified. +</para> + +<para> + To create materialized views supporting <acronym>IVM</acronym>, use the + <command>CREATE INCREMENTAL MATERIALIZED VIEW</command>, for example: +<programlisting> +CREATE <emphasis>INCREMENTAL</emphasis> MATERIALIZED VIEW mymatview AS SELECT * FROM mytab; +</programlisting> + When a materialized view is created with the <literal>INCREMENTAL</literal> + 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 + (<acronym>IMMV</acronym>). +<programlisting> +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) +</programlisting> +</para> + +<para> + Some <acronym>IMMV</acronym>s have hidden columns which are added + automatically when a materialized view is created. Their name starts + with <literal>__ivm_</literal> and they contain information required + for maintaining the <acronym>IMMV</acronym>. Such columns are not visible + when the <acronym>IMMV</acronym> is accessed by <literal>SELECT *</literal> + but are visible if the column name is explicitly specified in the target + list. We can also see the hidden columns in <literal>\d</literal> + meta-commands of <command>psql</command> commands. +</para> + +<para> + In general, <acronym>IMMV</acronym>s allow faster updates of materialized + views at the price of slower updates to their base tables. Updates of + <acronym>IMMV</acronym> is slower because triggers will be invoked and the + view is updated in triggers per modification statement. +</para> + +<para> + For example, suppose a normal materialized view defined as below: + +<programlisting> +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 + +</programlisting> + + Updating a tuple in a base table of this materialized view is rapid but the + <command>REFRESH MATERIALIZED VIEW</command> command on this view takes a long time: + +<programlisting> +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) +</programlisting> +</para> + +<para> + On the other hand, after creating <acronym>IMMV</acronym> with the same view + definition as below: + +<programlisting> +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" +</programlisting> + + 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 + <command>REFRESH MATERIALIZED VIEW</command> command. + +<programlisting> +test=# UPDATE pgbench_accounts SET abalance = 1000 WHERE aid = 1; +UPDATE 1 +Time: 13.068 ms +</programlisting> + +</para> + +<para> + Appropriate indexes on <acronym>IMMV</acronym>s are necessary for + efficient <acronym>IVM</acronym> because it looks for tuples to be + updated in <acronym>IMMV</acronym>. If there are no indexes, it + will take a long time. +</para> + +<para> + Therefore, when <acronym>IMMV</acronym> 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. +</para> + +<para> + 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. +<programlisting> +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) +</programlisting> + +</para> + +<para> + <acronym>IVM</acronym> 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, <acronym>IVM</acronym> + 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, <acronym>IVM</acronym> is not effective and the cost of + maintenance can be larger than the <command>REFRESH MATERIALIZED VIEW</command> + command. In such situation, we can use <command>REFRESH MATERIALIZED VIEW</command> + and specify <literal>WITH NO DATA</literal> to disable immediate + maintenance before modifying a base table. After a base table modification, + execute the <command>REFRESH MATERIALIZED VIEW</command> (with <literal>WITH DATA</literal>) + command to refresh the view data and enable immediate maintenance. +</para> + +</sect2> + +<sect2 id="rules-ivm-support"> +<title>Supported View Definitions and Restrictions</title> + +<para> + Currently, we can create <acronym>IMMV</acronym>s using inner joins, and some + aggregates. However, several restrictions apply to the definition of IMMV. +</para> + +<sect3 id="rules-ivm-support-joins"> +<title>Joins</title> +<para> + Inner joins including self-join are supported. Outer joins are not supported. +</para> +</sect3> + +<sect3 id="rules-ivm-support-aggregates"> +<title>Aggregates</title> +<para> + Supported aggregate functions are <function>count</function>, <function>sum</function>, + <function>avg</function>, <function>min</function>, and <function>max</function>. + 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 <acronym>IMMV</acronym>. +</para> + +<para> + Note that for <function>min</function> or <function>max</function>, 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 <acronym>IMMV</acronym> containing + these functions. +</para> + +<para> + Also note that using <function>sum</function> or <function>avg</function> on + <type>real</type> (<type>float4</type>) type or <type>double precision</type> + (<type>float8</type>) type in <acronym>IMMV</acronym> is unsafe. This is + because aggregated values in <acronym>IMMV</acronym> can become different from + results calculated from base tables due to the limited precision of these types. + To avoid this problem, use the <type>numeric</type> type instead. +</para> + + <sect4 id="rules-ivm-restrictions-aggregates"> + <title>Restrictions on Aggregates</title> + <para> + There are the following restrictions: + <itemizedlist> + <listitem> + <para> + If we have a <literal>GROUP BY</literal> clause, expressions specified in + <literal>GROUP BY</literal> must appear in the target list. This is + how tuples to be updated in the <acronym>IMMV</acronym> are identified. + These attributes are used as scan keys for searching tuples in the + <acronym>IMMV</acronym>, so indexes on them are required for efficient + <acronym>IVM</acronym>. + </para> + </listitem> + + <listitem> + <para> + <literal>HAVING</literal> clause cannot be used. + </para> + </listitem> + </itemizedlist> + </para> + </sect4> +</sect3> + +<sect3 id="rules-ivm-general-restricitons"> +<title>Other General Restrictions</title> +<para> + There are other restrictions which generally apply to <acronym>IMMV</acronym>: + <itemizedlist> + <listitem> + <para> + Sub-queries cannot be used. + </para> + </listitem> + + <listitem> + <para> + CTEs cannot be used. + </para> + </listitem> + + <listitem> + <para> + Window functions cannot be used. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s must be based on simple base tables. It's not + supported to create them on top of views, materialized views, foreign tables, inhe. + </para> + </listitem> + + <listitem> + <para> + LIMIT and OFFSET clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s cannot contain system columns. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s cannot contain non-immutable functions. + </para> + </listitem> + + <listitem> + <para> + UNION/INTERSECT/EXCEPT clauses cannnot be used. + </para> + </listitem> + + <listitem> + <para> + DISTINCT ON clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + TABLESAMPLE parameter cannot be used. + </para> + </listitem> + + <listitem> + <para> + inheritance parent tables cannnot be used. + </para> + </listitem> + + <listitem> + <para> + VALUES clause cannnot be used. + </para> + </listitem> + + <listitem> + <para> + <literal>GROUPING SETS</literal> and <literal>FILTER</literal> clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + FOR UPDATE/SHARE cannot be used. + </para> + </listitem> + + <listitem> + <para> + targetlist cannot contain columns whose name start with <literal>__ivm_</literal>. + </para> + </listitem> + + <listitem> + <para> + targetlist cannot contain expressions which contain an aggregate in it. + </para> + </listitem> + + <listitem> + <para> + Logical replication is not supported, that is, even when a base table + at a publisher node is modified, <acronym>IMMV</acronym>s at subscriber + nodes are not updated. + </para> + </listitem> + + </itemizedlist> +</para> +</sect3> + +</sect2> + +<sect2 id="rules-ivm-distinct"> +<title><literal>DISTINCT</literal></title> + +<para> + <productname>PostgreSQL</productname> supports <acronym>IMMV</acronym> with + <literal>DISTINCT</literal>. For example, suppose a <acronym>IMMV</acronym> + defined with <literal>DISTINCT</literal> 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. +</para> + +<para> + Physically, an <acronym>IMMV</acronym> defined with <literal>DISTINCT</literal> + contains tuples after eliminating duplicates, and the multiplicity of each tuple + is stored in a hidden column named <literal>__ivm_count__</literal>. +</para> +</sect2> + +<sect2 id="rules-ivm-concurrent-transactions"> +<title>Concurrent Transactions</title> +<para> + Suppose an <acronym>IMMV</acronym> is defined on two base tables and each + table was modified in different a concurrent transaction simultaneously. + In the transaction which was committed first, <acronym>IMMV</acronym> 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, <literal>ExclusiveLock</literal> + is held on an <acronym>IMMV</acronym> immediately after a base table is + modified in <literal>READ COMMITTED</literal> mode to make sure that + the <acronym>IMMV</acronym> is updated in the latter transaction after + the former transaction is committed. In <literal>REPEATABLE READ</literal> + or <literal>SERIALIZABLE</literal> 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 + <acronym>IMMV</acronym> cannot be updated correctly in such situations. + However, as an exception if the view has only one base table and + <command>INSERT</command> is performed on the table, + the lock held on thew view is <literal>RowExclusiveLock</literal>. +</para> +</sect2> + +<sect2 id="rules-ivm-rls"> +<title>Row Level Security</title> +<para> + 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. +</para> +</sect2> + +</sect1> + <sect1 id="rules-update"> <title>Rules on <command>INSERT</command>, <command>UPDATE</command>, and <command>DELETE</command></title> diff --git a/doc/src/sgml/system-views.sgml b/doc/src/sgml/system-views.sgml index 3c8dca8ca3..da22606213 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 </para></entry> </row> + <row> + <entry role="catalog_table_entry"><para role="column_definition"> + <structfield>isimmv</structfield> <type>bool</type> + </para> + <para> + True if materialized view is incrementally maintainable + </para></entry> + </row> + <row> <entry role="catalog_table_entry"><para role="column_definition"> <structfield>definition</structfield> <type>text</type> -- 2.25.1 --Multipart=_Sun__31_Mar_2024_22_59_31_+0900_msknEviJj08_wgqO-- ^ permalink raw reply [nested|flat] 22+ messages in thread
* [PATCH v27 9/9] Add documentations about Incremental View Maintenance @ 2019-12-20 01:25 Yugo Nagata <[email protected]> 0 siblings, 0 replies; 22+ messages in thread From: Yugo Nagata @ 2019-12-20 01:25 UTC (permalink / raw) --- doc/src/sgml/catalogs.sgml | 24 +- .../sgml/ref/create_materialized_view.sgml | 131 +++++- .../sgml/ref/refresh_materialized_view.sgml | 8 +- doc/src/sgml/rules.sgml | 443 ++++++++++++++++++ 4 files changed, 601 insertions(+), 5 deletions(-) diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml index a533a2153e..2561faa163 100644 --- a/doc/src/sgml/catalogs.sgml +++ b/doc/src/sgml/catalogs.sgml @@ -2193,6 +2193,15 @@ SCRAM-SHA-256$<replaceable><iteration count></replaceable>:<replaceable>&l </para></entry> </row> + <row> + <entry role="catalog_table_entry"><para role="column_definition"> + <structfield>relisivm</structfield> <type>bool</type> + </para> + <para> + True if materialized view enables incremental view maintenance + </para></entry> + </row> + <row> <entry role="catalog_table_entry"><para role="column_definition"> <structfield>relrewrite</structfield> <type>oid</type> @@ -3508,6 +3517,18 @@ SCRAM-SHA-256$<replaceable><iteration count></replaceable>:<replaceable>&l </para> </listitem> </varlistentry> + + <varlistentry> + <term><symbol>DEPENDENCY_IMMV</symbol> (<literal>m</literal>)</term> + <listitem> + <para> + The dependent object was created as part of creation of the Materialized + View with Incremental View Maintenance reference, and is really just a + part of its internal implementation. The dependent object must not be + dropped unless the materialized view is also dropped. + </para> + </listitem> + </varlistentry> </variablelist> Other dependency flavors might be needed in future. @@ -3891,7 +3912,8 @@ SCRAM-SHA-256$<replaceable><iteration count></replaceable>:<replaceable>&l <structfield>extrelocatable</structfield> <type>bool</type> </para> <para> - True if extension can be relocated to another schema + True for materialized views which are enabled for incremental + view maintenance (IVM). </para></entry> </row> diff --git a/doc/src/sgml/ref/create_materialized_view.sgml b/doc/src/sgml/ref/create_materialized_view.sgml index 0d2fea2b97..52a4d206b1 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 <refsynopsisdiv> <synopsis> -CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> +CREATE [ INCREMENTAL ] MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> [ (<replaceable>column_name</replaceable> [, ...] ) ] [ USING <replaceable class="parameter">method</replaceable> ] [ WITH ( <replaceable class="parameter">storage_parameter</replaceable> [= <replaceable class="parameter">value</replaceable>] [, ... ] ) ] @@ -60,6 +60,132 @@ CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> <title>Parameters</title> <variablelist> + <varlistentry> + <term><literal>INCREMENTAL</literal></term> + <listitem> + <para> + 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). + </para> + <para> + When <acronym>IMMV</acronym> is defined without using <command>WITH NO DATA</command>, + 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. + </para> + <para> + There are restrictions of query definitions allowed to use this + option. The following are supported in query definitions for IMMV: + <itemizedlist> + + <listitem> + <para> + Inner joins (including self-joins). + </para> + </listitem> + + <listitem> + <para> + Some built-in aggregate functions (count, sum, avg, min, max) without a HAVING + clause. + </para> + </listitem> + </itemizedlist> + + Unsupported queries with this option include the following: + + <itemizedlist> + <listitem> + <para> + Outer joins. + </para> + </listitem> + + <listitem> + <para> + Sub-queries. + </para> + </listitem> + + <listitem> + <para> + Aggregate functions other than built-in count, sum, avg, min and max. + </para> + </listitem> + <listitem> + <para> + Aggregate functions with a HAVING clause. + </para> + </listitem> + <listitem> + <para> + DISTINCT ON, WINDOW, VALUES, LIMIT and OFFSET clause. + </para> + </listitem> + </itemizedlist> + + Other restrictions include: + <itemizedlist> + + <listitem> + <para> + IMMVs must be based on simple base tables. It's not supported to + create them on top of views or materialized views. + </para> + </listitem> + + <listitem> + <para> + When the TRUNCATE command is executed on a base table, + no changes are made to the materialized view. + </para> + </listitem> + + <listitem> + <para> + It is not supported to include system columns in an IMMV. + <programlisting> +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 + </programlisting> + </para> + </listitem> + + <listitem> + <para> + Non-immutable functions are not supported. + <programlisting> +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 + </programlisting> + </para> + </listitem> + + <listitem> + <para> + IMMVs do not support expressions that contains aggregates + </para> + </listitem> + + <listitem> + <para> + Logical replication does not support IMMVs. + </para> + </listitem> + + </itemizedlist> + + </para> + </listitem> + </varlistentry> + <varlistentry> <term><literal>IF NOT EXISTS</literal></term> <listitem> @@ -155,7 +281,8 @@ CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> 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 <command>REFRESH - MATERIALIZED VIEW</command> is used. + MATERIALIZED VIEW</command> is used. Also, if the view is IMMV, + triggers for maintaining the view are not created. </para> </listitem> </varlistentry> 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 ] <replaceable class="parameter">name</ owner of the materialized view. The old contents are discarded. If <literal>WITH DATA</literal> 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 <literal>WITH NO DATA</literal> 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 <literal>WITH NO DATA</literal> 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. </para> <para> <literal>CONCURRENTLY</literal> and <literal>WITH NO DATA</literal> may not diff --git a/doc/src/sgml/rules.sgml b/doc/src/sgml/rules.sgml index 4b2ba5a4e6..71e10ef5a1 100644 --- a/doc/src/sgml/rules.sgml +++ b/doc/src/sgml/rules.sgml @@ -1090,6 +1090,449 @@ SELECT word FROM words ORDER BY word <-> 'caterpiler' LIMIT 10; </sect1> +<sect1 id="rules-ivm"> +<title>Incremental View Maintenance</title> + +<indexterm zone="rules-ivm"> + <primary>incremental view maintenance</primary> +</indexterm> + +<indexterm zone="rules-ivm"> + <primary>materialized view</primary> + <secondary>incremental view maintenance</secondary> +</indexterm> + +<indexterm zone="rules-ivm"> + <primary>view</primary> + <secondary>incremental view maintenance</secondary> +</indexterm> + +<sect2 id="rules-ivm-overview"> +<title>Overview</title> + +<para> + Incremental View Maintenance (<acronym>IVM</acronym>) 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 + <command>REFRESH MATERIALIZED VIEW</command> does. <acronym>IVM</acronym> + can update materialized views more efficiently than recomputation when only + small parts of the view are changed. +</para> + +<para> + 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 <command>REFRESH + MATERIALIZED VIEW</command>, or periodically in background, and so on. + <productname>PostgreSQL</productname> currently implements only a kind of + immediate maintenance, in which materialized views are updated immediately + in AFTER triggers when a base table is modified. +</para> + +<para> + To create materialized views supporting <acronym>IVM</acronym>, use the + <command>CREATE INCREMENTAL MATERIALIZED VIEW</command>, for example: +<programlisting> +CREATE <emphasis>INCREMENTAL</emphasis> MATERIALIZED VIEW mymatview AS SELECT * FROM mytab; +</programlisting> + When a materialized view is created with the <literal>INCREMENTAL</literal> + 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 + (<acronym>IMMV</acronym>). +<programlisting> +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) +</programlisting> +</para> + +<para> + Some <acronym>IMMV</acronym>s have hidden columns which are added + automatically when a materialized view is created. Their name starts + with <literal>__ivm_</literal> and they contain information required + for maintaining the <acronym>IMMV</acronym>. Such columns are not visible + when the <acronym>IMMV</acronym> is accessed by <literal>SELECT *</literal> + but are visible if the column name is explicitly specified in the target + list. We can also see the hidden columns in <literal>\d</literal> + meta-commands of <command>psql</command> commands. +</para> + +<para> + In general, <acronym>IMMV</acronym>s allow faster updates of materialized + views at the price of slower updates to their base tables. Updates of + <acronym>IMMV</acronym> is slower because triggers will be invoked and the + view is updated in triggers per modification statement. +</para> + +<para> + For example, suppose a normal materialized view defined as below: + +<programlisting> +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 + +</programlisting> + + Updating a tuple in a base table of this materialized view is rapid but the + <command>REFRESH MATERIALIZED VIEW</command> command on this view takes a long time: + +<programlisting> +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) +</programlisting> +</para> + +<para> + On the other hand, after creating <acronym>IMMV</acronym> with the same view + definition as below: + +<programlisting> +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" +</programlisting> + + 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 + <command>REFRESH MATERIALIZED VIEW</command> command. + +<programlisting> +test=# UPDATE pgbench_accounts SET abalance = 1000 WHERE aid = 1; +UPDATE 1 +Time: 13.068 ms +</programlisting> + +</para> + +<para> + Appropriate indexes on <acronym>IMMV</acronym>s are necessary for + efficient <acronym>IVM</acronym> because it looks for tuples to be + updated in <acronym>IMMV</acronym>. If there are no indexes, it + will take a long time. +</para> + +<para> + Therefore, when <acronym>IMMV</acronym> 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. +</para> + +<para> + 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. +<programlisting> +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) +</programlisting> + +</para> + +<para> + <acronym>IVM</acronym> 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, <acronym>IVM</acronym> + 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, <acronym>IVM</acronym> is not effective and the cost of + maintenance can be larger than the <command>REFRESH MATERIALIZED VIEW</command> + command. In such situation, we can use <command>REFRESH MATERIALIZED VIEW</command> + and specify <literal>WITH NO DATA</literal> to disable immediate + maintenance before modifying a base table. After a base table modification, + execute the <command>REFRESH MATERIALIZED VIEW</command> (with <literal>WITH DATA</literal>) + command to refresh the view data and enable immediate maintenance. +</para> + +</sect2> + +<sect2> +<title>Supported View Definitions and Restrictions</title> + +<para> + Currently, we can create <acronym>IMMV</acronym>s using inner joins, and some + aggregates. However, several restrictions apply to the definition of IMMV. +</para> + +<sect3> +<title>Joins</title> +<para> + Inner joins including self-join are supported. Outer joins are not supported. +</para> +</sect3> + +<sect3> +<title>Aggregates</title> +<para> + Supported aggregate functions are <function>count</function>, <function>sum</function>, + <function>avg</function>, <function>min</function>, and <function>max</function>. + 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 <acronym>IMMV</acronym>. +</para> + +<para> + Note that for <function>min</function> or <function>max</function>, 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 <acronym>IMMV</acronym> containing + these functions. +</para> + +<para> + Also note that using <function>sum</function> or <function>avg</function> on + <type>real</type> (<type>float4</type>) type or <type>double precision</type> + (<type>float8</type>) type in <acronym>IMMV</acronym> is unsafe. This is + because aggregated values in <acronym>IMMV</acronym> can become different from + results calculated from base tables due to the limited precision of these types. + To avoid this problem, use the <type>numeric</type> type instead. +</para> + + <sect4> + <title>Restrictions on Aggregates</title> + <para> + There are the following restrictions: + <itemizedlist> + <listitem> + <para> + If we have a <literal>GROUP BY</literal> clause, expressions specified in + <literal>GROUP BY</literal> must appear in the target list. This is + how tuples to be updated in the <acronym>IMMV</acronym> are identified. + These attributes are used as scan keys for searching tuples in the + <acronym>IMMV</acronym>, so indexes on them are required for efficient + <acronym>IVM</acronym>. + </para> + </listitem> + + <listitem> + <para> + <literal>HAVING</literal> clause cannot be used. + </para> + </listitem> + </itemizedlist> + </para> + </sect4> +</sect3> + +<sect3> +<title>Other General Restrictions</title> +<para> + There are other restrictions which generally apply to <acronym>IMMV</acronym>: + <itemizedlist> + <listitem> + <para> + Sub-queries cannot be used. + </para> + </listitem> + + <listitem> + <para> + CTEs cannot be used. + </para> + </listitem> + + <listitem> + <para> + Window functions cannot be used. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s must be based on simple base tables. It's not + supported to create them on top of views, materialized views, foreign tables, inhe. + </para> + </listitem> + + <listitem> + <para> + LIMIT and OFFSET clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s cannot contain system columns. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s cannot contain non-immutable functions. + </para> + </listitem> + + <listitem> + <para> + UNION/INTERSECT/EXCEPT clauses cannnot be used. + </para> + </listitem> + + <listitem> + <para> + DISTINCT ON clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + TABLESAMPLE parameter cannot be used. + </para> + </listitem> + + <listitem> + <para> + inheritance parent tables cannnot be used. + </para> + </listitem> + + <listitem> + <para> + VALUES clause cannnot be used. + </para> + </listitem> + + <listitem> + <para> + <literal>GROUPING SETS</literal> and <literal>FILTER</literal> clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + FOR UPDATE/SHARE cannot be used. + </para> + </listitem> + + <listitem> + <para> + targetlist cannot contain columns whose name start with <literal>__ivm_</literal>. + </para> + </listitem> + + <listitem> + <para> + targetlist cannot contain expressions which contain an aggregate in it. + </para> + </listitem> + + <listitem> + <para> + Logical replication is not supported, that is, even when a base table + at a publisher node is modified, <acronym>IMMV</acronym>s at subscriber + nodes are not updated. + </para> + </listitem> + + <listitem> + <para> + When the <literal>TRUNCATE</literal> command is executed on a base table, + nothing is changed on the <acronym>IMMV</acronym>. + </para> + </listitem> + + </itemizedlist> +</para> +</sect3> + +</sect2> + +<sect2> +<title><literal>DISTINCT</literal></title> + +<para> + <productname>PostgreSQL</productname> supports <acronym>IMMV</acronym> with + <literal>DISTINCT</literal>. For example, suppose a <acronym>IMMV</acronym> + defined with <literal>DISTINCT</literal> 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. +</para> + +<para> + Physically, an <acronym>IMMV</acronym> defined with <literal>DISTINCT</literal> + contains tuples after eliminating duplicates, and the multiplicity of each tuple + is stored in a hidden column named <literal>__ivm_count__</literal>. +</para> +</sect2> + +<sect2> +<title>Concurrent Transactions</title> +<para> + Suppose an <acronym>IMMV</acronym> is defined on two base tables and each + table was modified in different a concurrent transaction simultaneously. + In the transaction which was committed first, <acronym>IMMV</acronym> 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, <literal>ExclusiveLock</literal> + is held on an <acronym>IMMV</acronym> immediately after a base table is + modified in <literal>READ COMMITTED</literal> mode to make sure that + the <acronym>IMMV</acronym> is updated in the latter transaction after + the former transaction is committed. In <literal>REPEATABLE READ</literal> + or <literal>SERIALIZABLE</literal> 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 + <acronym>IMMV</acronym> cannot be updated correctly in such situations. + However, as an exception if the view has only one base table, + the lock held on thew view is <literal>RowExclusiveLock</literal>. +</para> +</sect2> + +<sect2> +<title>Row Level Security</title> +<para> + 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. +</para> +</sect2> + +</sect1> + <sect1 id="rules-update"> <title>Rules on <command>INSERT</command>, <command>UPDATE</command>, and <command>DELETE</command></title> -- 2.17.1 --Multipart=_Fri__22_Apr_2022_11_29_39_+0900_ZOAC7UMt5e8j1Nvx-- ^ permalink raw reply [nested|flat] 22+ messages in thread
* [PATCH v27 9/9] Add documentations about Incremental View Maintenance @ 2019-12-20 01:25 Yugo Nagata <[email protected]> 0 siblings, 0 replies; 22+ messages in thread From: Yugo Nagata @ 2019-12-20 01:25 UTC (permalink / raw) --- doc/src/sgml/catalogs.sgml | 24 +- .../sgml/ref/create_materialized_view.sgml | 131 +++++- .../sgml/ref/refresh_materialized_view.sgml | 8 +- doc/src/sgml/rules.sgml | 443 ++++++++++++++++++ 4 files changed, 601 insertions(+), 5 deletions(-) diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml index a533a2153e..2561faa163 100644 --- a/doc/src/sgml/catalogs.sgml +++ b/doc/src/sgml/catalogs.sgml @@ -2193,6 +2193,15 @@ SCRAM-SHA-256$<replaceable><iteration count></replaceable>:<replaceable>&l </para></entry> </row> + <row> + <entry role="catalog_table_entry"><para role="column_definition"> + <structfield>relisivm</structfield> <type>bool</type> + </para> + <para> + True if materialized view enables incremental view maintenance + </para></entry> + </row> + <row> <entry role="catalog_table_entry"><para role="column_definition"> <structfield>relrewrite</structfield> <type>oid</type> @@ -3508,6 +3517,18 @@ SCRAM-SHA-256$<replaceable><iteration count></replaceable>:<replaceable>&l </para> </listitem> </varlistentry> + + <varlistentry> + <term><symbol>DEPENDENCY_IMMV</symbol> (<literal>m</literal>)</term> + <listitem> + <para> + The dependent object was created as part of creation of the Materialized + View with Incremental View Maintenance reference, and is really just a + part of its internal implementation. The dependent object must not be + dropped unless the materialized view is also dropped. + </para> + </listitem> + </varlistentry> </variablelist> Other dependency flavors might be needed in future. @@ -3891,7 +3912,8 @@ SCRAM-SHA-256$<replaceable><iteration count></replaceable>:<replaceable>&l <structfield>extrelocatable</structfield> <type>bool</type> </para> <para> - True if extension can be relocated to another schema + True for materialized views which are enabled for incremental + view maintenance (IVM). </para></entry> </row> diff --git a/doc/src/sgml/ref/create_materialized_view.sgml b/doc/src/sgml/ref/create_materialized_view.sgml index 0d2fea2b97..52a4d206b1 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 <refsynopsisdiv> <synopsis> -CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> +CREATE [ INCREMENTAL ] MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> [ (<replaceable>column_name</replaceable> [, ...] ) ] [ USING <replaceable class="parameter">method</replaceable> ] [ WITH ( <replaceable class="parameter">storage_parameter</replaceable> [= <replaceable class="parameter">value</replaceable>] [, ... ] ) ] @@ -60,6 +60,132 @@ CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> <title>Parameters</title> <variablelist> + <varlistentry> + <term><literal>INCREMENTAL</literal></term> + <listitem> + <para> + 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). + </para> + <para> + When <acronym>IMMV</acronym> is defined without using <command>WITH NO DATA</command>, + 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. + </para> + <para> + There are restrictions of query definitions allowed to use this + option. The following are supported in query definitions for IMMV: + <itemizedlist> + + <listitem> + <para> + Inner joins (including self-joins). + </para> + </listitem> + + <listitem> + <para> + Some built-in aggregate functions (count, sum, avg, min, max) without a HAVING + clause. + </para> + </listitem> + </itemizedlist> + + Unsupported queries with this option include the following: + + <itemizedlist> + <listitem> + <para> + Outer joins. + </para> + </listitem> + + <listitem> + <para> + Sub-queries. + </para> + </listitem> + + <listitem> + <para> + Aggregate functions other than built-in count, sum, avg, min and max. + </para> + </listitem> + <listitem> + <para> + Aggregate functions with a HAVING clause. + </para> + </listitem> + <listitem> + <para> + DISTINCT ON, WINDOW, VALUES, LIMIT and OFFSET clause. + </para> + </listitem> + </itemizedlist> + + Other restrictions include: + <itemizedlist> + + <listitem> + <para> + IMMVs must be based on simple base tables. It's not supported to + create them on top of views or materialized views. + </para> + </listitem> + + <listitem> + <para> + When the TRUNCATE command is executed on a base table, + no changes are made to the materialized view. + </para> + </listitem> + + <listitem> + <para> + It is not supported to include system columns in an IMMV. + <programlisting> +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 + </programlisting> + </para> + </listitem> + + <listitem> + <para> + Non-immutable functions are not supported. + <programlisting> +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 + </programlisting> + </para> + </listitem> + + <listitem> + <para> + IMMVs do not support expressions that contains aggregates + </para> + </listitem> + + <listitem> + <para> + Logical replication does not support IMMVs. + </para> + </listitem> + + </itemizedlist> + + </para> + </listitem> + </varlistentry> + <varlistentry> <term><literal>IF NOT EXISTS</literal></term> <listitem> @@ -155,7 +281,8 @@ CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> 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 <command>REFRESH - MATERIALIZED VIEW</command> is used. + MATERIALIZED VIEW</command> is used. Also, if the view is IMMV, + triggers for maintaining the view are not created. </para> </listitem> </varlistentry> 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 ] <replaceable class="parameter">name</ owner of the materialized view. The old contents are discarded. If <literal>WITH DATA</literal> 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 <literal>WITH NO DATA</literal> 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 <literal>WITH NO DATA</literal> 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. </para> <para> <literal>CONCURRENTLY</literal> and <literal>WITH NO DATA</literal> may not diff --git a/doc/src/sgml/rules.sgml b/doc/src/sgml/rules.sgml index 4b2ba5a4e6..71e10ef5a1 100644 --- a/doc/src/sgml/rules.sgml +++ b/doc/src/sgml/rules.sgml @@ -1090,6 +1090,449 @@ SELECT word FROM words ORDER BY word <-> 'caterpiler' LIMIT 10; </sect1> +<sect1 id="rules-ivm"> +<title>Incremental View Maintenance</title> + +<indexterm zone="rules-ivm"> + <primary>incremental view maintenance</primary> +</indexterm> + +<indexterm zone="rules-ivm"> + <primary>materialized view</primary> + <secondary>incremental view maintenance</secondary> +</indexterm> + +<indexterm zone="rules-ivm"> + <primary>view</primary> + <secondary>incremental view maintenance</secondary> +</indexterm> + +<sect2 id="rules-ivm-overview"> +<title>Overview</title> + +<para> + Incremental View Maintenance (<acronym>IVM</acronym>) 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 + <command>REFRESH MATERIALIZED VIEW</command> does. <acronym>IVM</acronym> + can update materialized views more efficiently than recomputation when only + small parts of the view are changed. +</para> + +<para> + 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 <command>REFRESH + MATERIALIZED VIEW</command>, or periodically in background, and so on. + <productname>PostgreSQL</productname> currently implements only a kind of + immediate maintenance, in which materialized views are updated immediately + in AFTER triggers when a base table is modified. +</para> + +<para> + To create materialized views supporting <acronym>IVM</acronym>, use the + <command>CREATE INCREMENTAL MATERIALIZED VIEW</command>, for example: +<programlisting> +CREATE <emphasis>INCREMENTAL</emphasis> MATERIALIZED VIEW mymatview AS SELECT * FROM mytab; +</programlisting> + When a materialized view is created with the <literal>INCREMENTAL</literal> + 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 + (<acronym>IMMV</acronym>). +<programlisting> +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) +</programlisting> +</para> + +<para> + Some <acronym>IMMV</acronym>s have hidden columns which are added + automatically when a materialized view is created. Their name starts + with <literal>__ivm_</literal> and they contain information required + for maintaining the <acronym>IMMV</acronym>. Such columns are not visible + when the <acronym>IMMV</acronym> is accessed by <literal>SELECT *</literal> + but are visible if the column name is explicitly specified in the target + list. We can also see the hidden columns in <literal>\d</literal> + meta-commands of <command>psql</command> commands. +</para> + +<para> + In general, <acronym>IMMV</acronym>s allow faster updates of materialized + views at the price of slower updates to their base tables. Updates of + <acronym>IMMV</acronym> is slower because triggers will be invoked and the + view is updated in triggers per modification statement. +</para> + +<para> + For example, suppose a normal materialized view defined as below: + +<programlisting> +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 + +</programlisting> + + Updating a tuple in a base table of this materialized view is rapid but the + <command>REFRESH MATERIALIZED VIEW</command> command on this view takes a long time: + +<programlisting> +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) +</programlisting> +</para> + +<para> + On the other hand, after creating <acronym>IMMV</acronym> with the same view + definition as below: + +<programlisting> +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" +</programlisting> + + 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 + <command>REFRESH MATERIALIZED VIEW</command> command. + +<programlisting> +test=# UPDATE pgbench_accounts SET abalance = 1000 WHERE aid = 1; +UPDATE 1 +Time: 13.068 ms +</programlisting> + +</para> + +<para> + Appropriate indexes on <acronym>IMMV</acronym>s are necessary for + efficient <acronym>IVM</acronym> because it looks for tuples to be + updated in <acronym>IMMV</acronym>. If there are no indexes, it + will take a long time. +</para> + +<para> + Therefore, when <acronym>IMMV</acronym> 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. +</para> + +<para> + 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. +<programlisting> +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) +</programlisting> + +</para> + +<para> + <acronym>IVM</acronym> 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, <acronym>IVM</acronym> + 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, <acronym>IVM</acronym> is not effective and the cost of + maintenance can be larger than the <command>REFRESH MATERIALIZED VIEW</command> + command. In such situation, we can use <command>REFRESH MATERIALIZED VIEW</command> + and specify <literal>WITH NO DATA</literal> to disable immediate + maintenance before modifying a base table. After a base table modification, + execute the <command>REFRESH MATERIALIZED VIEW</command> (with <literal>WITH DATA</literal>) + command to refresh the view data and enable immediate maintenance. +</para> + +</sect2> + +<sect2> +<title>Supported View Definitions and Restrictions</title> + +<para> + Currently, we can create <acronym>IMMV</acronym>s using inner joins, and some + aggregates. However, several restrictions apply to the definition of IMMV. +</para> + +<sect3> +<title>Joins</title> +<para> + Inner joins including self-join are supported. Outer joins are not supported. +</para> +</sect3> + +<sect3> +<title>Aggregates</title> +<para> + Supported aggregate functions are <function>count</function>, <function>sum</function>, + <function>avg</function>, <function>min</function>, and <function>max</function>. + 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 <acronym>IMMV</acronym>. +</para> + +<para> + Note that for <function>min</function> or <function>max</function>, 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 <acronym>IMMV</acronym> containing + these functions. +</para> + +<para> + Also note that using <function>sum</function> or <function>avg</function> on + <type>real</type> (<type>float4</type>) type or <type>double precision</type> + (<type>float8</type>) type in <acronym>IMMV</acronym> is unsafe. This is + because aggregated values in <acronym>IMMV</acronym> can become different from + results calculated from base tables due to the limited precision of these types. + To avoid this problem, use the <type>numeric</type> type instead. +</para> + + <sect4> + <title>Restrictions on Aggregates</title> + <para> + There are the following restrictions: + <itemizedlist> + <listitem> + <para> + If we have a <literal>GROUP BY</literal> clause, expressions specified in + <literal>GROUP BY</literal> must appear in the target list. This is + how tuples to be updated in the <acronym>IMMV</acronym> are identified. + These attributes are used as scan keys for searching tuples in the + <acronym>IMMV</acronym>, so indexes on them are required for efficient + <acronym>IVM</acronym>. + </para> + </listitem> + + <listitem> + <para> + <literal>HAVING</literal> clause cannot be used. + </para> + </listitem> + </itemizedlist> + </para> + </sect4> +</sect3> + +<sect3> +<title>Other General Restrictions</title> +<para> + There are other restrictions which generally apply to <acronym>IMMV</acronym>: + <itemizedlist> + <listitem> + <para> + Sub-queries cannot be used. + </para> + </listitem> + + <listitem> + <para> + CTEs cannot be used. + </para> + </listitem> + + <listitem> + <para> + Window functions cannot be used. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s must be based on simple base tables. It's not + supported to create them on top of views, materialized views, foreign tables, inhe. + </para> + </listitem> + + <listitem> + <para> + LIMIT and OFFSET clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s cannot contain system columns. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s cannot contain non-immutable functions. + </para> + </listitem> + + <listitem> + <para> + UNION/INTERSECT/EXCEPT clauses cannnot be used. + </para> + </listitem> + + <listitem> + <para> + DISTINCT ON clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + TABLESAMPLE parameter cannot be used. + </para> + </listitem> + + <listitem> + <para> + inheritance parent tables cannnot be used. + </para> + </listitem> + + <listitem> + <para> + VALUES clause cannnot be used. + </para> + </listitem> + + <listitem> + <para> + <literal>GROUPING SETS</literal> and <literal>FILTER</literal> clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + FOR UPDATE/SHARE cannot be used. + </para> + </listitem> + + <listitem> + <para> + targetlist cannot contain columns whose name start with <literal>__ivm_</literal>. + </para> + </listitem> + + <listitem> + <para> + targetlist cannot contain expressions which contain an aggregate in it. + </para> + </listitem> + + <listitem> + <para> + Logical replication is not supported, that is, even when a base table + at a publisher node is modified, <acronym>IMMV</acronym>s at subscriber + nodes are not updated. + </para> + </listitem> + + <listitem> + <para> + When the <literal>TRUNCATE</literal> command is executed on a base table, + nothing is changed on the <acronym>IMMV</acronym>. + </para> + </listitem> + + </itemizedlist> +</para> +</sect3> + +</sect2> + +<sect2> +<title><literal>DISTINCT</literal></title> + +<para> + <productname>PostgreSQL</productname> supports <acronym>IMMV</acronym> with + <literal>DISTINCT</literal>. For example, suppose a <acronym>IMMV</acronym> + defined with <literal>DISTINCT</literal> 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. +</para> + +<para> + Physically, an <acronym>IMMV</acronym> defined with <literal>DISTINCT</literal> + contains tuples after eliminating duplicates, and the multiplicity of each tuple + is stored in a hidden column named <literal>__ivm_count__</literal>. +</para> +</sect2> + +<sect2> +<title>Concurrent Transactions</title> +<para> + Suppose an <acronym>IMMV</acronym> is defined on two base tables and each + table was modified in different a concurrent transaction simultaneously. + In the transaction which was committed first, <acronym>IMMV</acronym> 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, <literal>ExclusiveLock</literal> + is held on an <acronym>IMMV</acronym> immediately after a base table is + modified in <literal>READ COMMITTED</literal> mode to make sure that + the <acronym>IMMV</acronym> is updated in the latter transaction after + the former transaction is committed. In <literal>REPEATABLE READ</literal> + or <literal>SERIALIZABLE</literal> 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 + <acronym>IMMV</acronym> cannot be updated correctly in such situations. + However, as an exception if the view has only one base table, + the lock held on thew view is <literal>RowExclusiveLock</literal>. +</para> +</sect2> + +<sect2> +<title>Row Level Security</title> +<para> + 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. +</para> +</sect2> + +</sect1> + <sect1 id="rules-update"> <title>Rules on <command>INSERT</command>, <command>UPDATE</command>, and <command>DELETE</command></title> -- 2.17.1 --Multipart=_Fri__22_Apr_2022_14_58_01_+0900_MN3L/o2YUVF2g4zw-- ^ permalink raw reply [nested|flat] 22+ messages in thread
* [PATCH v25 10/15] Add documentations about Incremental View Maintenance @ 2019-12-20 01:25 Yugo Nagata <[email protected]> 0 siblings, 0 replies; 22+ messages in thread From: Yugo Nagata @ 2019-12-20 01:25 UTC (permalink / raw) --- doc/src/sgml/catalogs.sgml | 24 +- .../sgml/ref/create_materialized_view.sgml | 131 +++++- .../sgml/ref/refresh_materialized_view.sgml | 6 +- doc/src/sgml/rules.sgml | 443 ++++++++++++++++++ 4 files changed, 599 insertions(+), 5 deletions(-) diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml index 7d5b0b1656..7c07ac8ece 100644 --- a/doc/src/sgml/catalogs.sgml +++ b/doc/src/sgml/catalogs.sgml @@ -2188,6 +2188,15 @@ SCRAM-SHA-256$<replaceable><iteration count></replaceable>:<replaceable>&l </para></entry> </row> + <row> + <entry role="catalog_table_entry"><para role="column_definition"> + <structfield>relisivm</structfield> <type>bool</type> + </para> + <para> + True if materialized view enables incremental view maintenance + </para></entry> + </row> + <row> <entry role="catalog_table_entry"><para role="column_definition"> <structfield>relrewrite</structfield> <type>oid</type> @@ -3474,6 +3483,18 @@ SCRAM-SHA-256$<replaceable><iteration count></replaceable>:<replaceable>&l </para> </listitem> </varlistentry> + + <varlistentry> + <term><symbol>DEPENDENCY_IMMV</symbol> (<literal>m</literal>)</term> + <listitem> + <para> + The dependent object was created as part of creation of the Materialized + View with Incremental View Maintenance reference, and is really just a + part of its internal implementation. The dependent object must not be + dropped unless the materialized view is also dropped. + </para> + </listitem> + </varlistentry> </variablelist> Other dependency flavors might be needed in future. @@ -3857,7 +3878,8 @@ SCRAM-SHA-256$<replaceable><iteration count></replaceable>:<replaceable>&l <structfield>extrelocatable</structfield> <type>bool</type> </para> <para> - True if extension can be relocated to another schema + True for materialized views which are enabled for incremental + view maintenance (IVM). </para></entry> </row> diff --git a/doc/src/sgml/ref/create_materialized_view.sgml b/doc/src/sgml/ref/create_materialized_view.sgml index 0d2fea2b97..c3bd46571f 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 <refsynopsisdiv> <synopsis> -CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> +CREATE [ INCREMENTAL ] MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> [ (<replaceable>column_name</replaceable> [, ...] ) ] [ USING <replaceable class="parameter">method</replaceable> ] [ WITH ( <replaceable class="parameter">storage_parameter</replaceable> [= <replaceable class="parameter">value</replaceable>] [, ... ] ) ] @@ -60,6 +60,132 @@ CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> <title>Parameters</title> <variablelist> + <varlistentry> + <term><literal>INCREMENTAL</literal></term> + <listitem> + <para> + 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). + </para> + <para> + When <acronym>IMMV</acronym> 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. + </para> + <para> + There are restrictions of query definitions allowed to use this + option. The following are supported in query definitions for IMMV: + <itemizedlist> + + <listitem> + <para> + Inner joins (including self-joins). + </para> + </listitem> + + <listitem> + <para> + Some built-in aggregate functions (count, sum, avg, min, max) without a HAVING + clause. + </para> + </listitem> + </itemizedlist> + + Unsupported queries with this option include the following: + + <itemizedlist> + <listitem> + <para> + Outer joins. + </para> + </listitem> + + <listitem> + <para> + Sub-queries. + </para> + </listitem> + + <listitem> + <para> + Aggregate functions other than built-in count, sum, avg, min and max. + </para> + </listitem> + <listitem> + <para> + Aggregate functions with a HAVING clause. + </para> + </listitem> + <listitem> + <para> + DISTINCT ON, WINDOW, VALUES, LIMIT and OFFSET clause. + </para> + </listitem> + </itemizedlist> + + Other restrictions include: + <itemizedlist> + + <listitem> + <para> + IMMVs must be based on simple base tables. It's not supported to + create them on top of views or materialized views. + </para> + </listitem> + + <listitem> + <para> + When the TRUNCATE command is executed on a base table, + no changes are made to the materialized view. + </para> + </listitem> + + <listitem> + <para> + It is not supported to include system columns in an IMMV. + <programlisting> +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 + </programlisting> + </para> + </listitem> + + <listitem> + <para> + Non-immutable functions are not supported. + <programlisting> +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 + </programlisting> + </para> + </listitem> + + <listitem> + <para> + IMMVs do not support expressions that contains aggregates + </para> + </listitem> + + <listitem> + <para> + Logical replication does not support IMMVs. + </para> + </listitem> + + </itemizedlist> + + </para> + </listitem> + </varlistentry> + <varlistentry> <term><literal>IF NOT EXISTS</literal></term> <listitem> @@ -155,7 +281,8 @@ CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> 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 <command>REFRESH - MATERIALIZED VIEW</command> is used. + MATERIALIZED VIEW</command> is used. Also, if the view is IMMV, + triggers for maintaining the view are not created. </para> </listitem> </varlistentry> diff --git a/doc/src/sgml/ref/refresh_materialized_view.sgml b/doc/src/sgml/ref/refresh_materialized_view.sgml index 675d6090f3..e0d15fdce0 100644 --- a/doc/src/sgml/ref/refresh_materialized_view.sgml +++ b/doc/src/sgml/ref/refresh_materialized_view.sgml @@ -35,9 +35,11 @@ REFRESH MATERIALIZED VIEW [ CONCURRENTLY ] <replaceable class="parameter">name</ owner of the materialized view. The old contents are discarded. If <literal>WITH DATA</literal> 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 <literal>WITH NO DATA</literal> is specified no new + scannable state. Also, if the view is an incrementally maintainable materialized + view (IMMV) and was unpopulated, triggers for maintaining + the view are created. If <literal>WITH NO DATA</literal> 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. </para> <para> <literal>CONCURRENTLY</literal> and <literal>WITH NO DATA</literal> may not diff --git a/doc/src/sgml/rules.sgml b/doc/src/sgml/rules.sgml index 4aa4e00e01..13a64eab7f 100644 --- a/doc/src/sgml/rules.sgml +++ b/doc/src/sgml/rules.sgml @@ -1090,6 +1090,449 @@ SELECT word FROM words ORDER BY word <-> 'caterpiler' LIMIT 10; </sect1> +<sect1 id="rules-ivm"> +<title>Incremental View Maintenance</title> + +<indexterm zone="rules-ivm"> + <primary>incremental view maintenance</primary> +</indexterm> + +<indexterm zone="rules-ivm"> + <primary>materialized view</primary> + <secondary>incremental view maintenance</secondary> +</indexterm> + +<indexterm zone="rules-ivm"> + <primary>view</primary> + <secondary>incremental view maintenance</secondary> +</indexterm> + +<sect2 id="rules-ivm-overview"> +<title>Overview</title> + +<para> + Incremental View Maintenance (<acronym>IVM</acronym>) 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 + <command>REFRESH MATERIALIZED VIEW</command> does. <acronym>IVM</acronym> + can update materialized views more efficiently than recomputation when only + small parts of the view are changed. +</para> + +<para> + 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 <command>REFRESH + MATERIALIZED VIEW</command>, or periodically in background, and so on. + <productname>PostgreSQL</productname> currently implements only a kind of + immediate maintenance, in which materialized views are updated immediately + in AFTER triggers when a base table is modified. +</para> + +<para> + To create materialized views supporting <acronym>IVM</acronym>, use the + <command>CREATE INCREMENTAL MATERIALIZED VIEW</command>, for example: +<programlisting> +CREATE <emphasis>INCREMENTAL</emphasis> MATERIALIZED VIEW mymatview AS SELECT * FROM mytab; +</programlisting> + When a materialized view is created with the <literal>INCREMENTAL</literal> + 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 + (<acronym>IMMV</acronym>). +<programlisting> +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) +</programlisting> +</para> + +<para> + Some <acronym>IMMV</acronym>s have hidden columns which are added + automatically when a materialized view is created. Their name starts + with <literal>__ivm_</literal> and they contain information required + for maintaining the <acronym>IMMV</acronym>. Such columns are not visible + when the <acronym>IMMV</acronym> is accessed by <literal>SELECT *</literal> + but are visible if the column name is explicitly specified in the target + list. We can also see the hidden columns in <literal>\d</literal> + meta-commands of <command>psql</command> commands. +</para> + +<para> + In general, <acronym>IMMV</acronym>s allow faster updates of materialized + views at the price of slower updates to their base tables. Updates of + <acronym>IMMV</acronym> is slower because triggers will be invoked and the + view is updated in triggers per modification statement. +</para> + +<para> + For example, suppose a normal materialized view defined as below: + +<programlisting> +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 + +</programlisting> + + Updating a tuple in a base table of this materialized view is rapid but the + <command>REFRESH MATERIALIZED VIEW</command> command on this view takes a long time: + +<programlisting> +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) +</programlisting> +</para> + +<para> + On the other hand, after creating <acronym>IMMV</acronym> with the same view + definition as below: + +<programlisting> +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" +</programlisting> + + 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 + <command>REFRESH MATERIALIZED VIEW</command> command. + +<programlisting> +test=# UPDATE pgbench_accounts SET abalance = 1000 WHERE aid = 1; +UPDATE 1 +Time: 13.068 ms +</programlisting> + +</para> + +<para> + Appropriate indexes on <acronym>IMMV</acronym>s are necessary for + efficient <acronym>IVM</acronym> because it looks for tuples to be + updated in <acronym>IMMV</acronym>. If there are no indexes, it + will take a long time. +</para> + +<para> + Therefore, when <acronym>IMMV</acronym> 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. +</para> + +<para> + 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. +<programlisting> +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) +</programlisting> + +</para> + +<para> + <acronym>IVM</acronym> 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, <acronym>IVM</acronym> + 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, <acronym>IVM</acronym> is not effective and the cost of + maintenance can be larger than the <command>REFRESH MATERIALIZED VIEW</command> + command. In such situation, we can use <command>REFRESH MATERIALIZED VIEW</command> + and specify <literal>WITH NO DATA</literal> to disable immediate + maintenance before modifying a base table. After a base table modification, + execute the <command>REFRESH MATERIALIZED VIEW</command> (with <literal>WITH DATA</literal>) + command to refresh the view data and enable immediate maintenance. +</para> + +</sect2> + +<sect2> +<title>Supported View Definitions and Restrictions</title> + +<para> + Currently, we can create <acronym>IMMV</acronym>s using inner joins, and some + aggregates. However, several restrictions apply to the definition of IMMV. +</para> + +<sect3> +<title>Joins</title> +<para> + Inner joins including self-join are supported. Outer joins are not supported. +</para> +</sect3> + +<sect3> +<title>Aggregates</title> +<para> + Supported aggregate functions are <function>count</function>, <function>sum</function>, + <function>avg</function>, <function>min</function>, and <function>max</function>. + 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 <acronym>IMMV</acronym>. +</para> + +<para> + Note that for <function>min</function> or <function>max</function>, 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 <acronym>IMMV</acronym> containing + these functions. +</para> + +<para> + Also note that using <function>sum</function> or <function>avg</function> on + <type>real</type> (<type>float4</type>) type or <type>double precision</type> + (<type>float8</type>) type in <acronym>IMMV</acronym> is unsafe. This is + because aggregated values in <acronym>IMMV</acronym> can become different from + results calculated from base tables due to the limited precision of these types. + To avoid this problem, use the <type>numeric</type> type instead. +</para> + + <sect4> + <title>Restrictions on Aggregates</title> + <para> + There are the following restrictions: + <itemizedlist> + <listitem> + <para> + If we have a <literal>GROUP BY</literal> clause, expressions specified in + <literal>GROUP BY</literal> must appear in the target list. This is + how tuples to be updated in the <acronym>IMMV</acronym> are identified. + These attributes are used as scan keys for searching tuples in the + <acronym>IMMV</acronym>, so indexes on them are required for efficient + <acronym>IVM</acronym>. + </para> + </listitem> + + <listitem> + <para> + <literal>HAVING</literal> clause cannot be used. + </para> + </listitem> + </itemizedlist> + </para> + </sect4> +</sect3> + +<sect3> +<title>Other General Restrictions</title> +<para> + There are other restrictions which generally apply to <acronym>IMMV</acronym>: + <itemizedlist> + <listitem> + <para> + Sub-queries cannot be used. + </para> + </listitem> + + <listitem> + <para> + CTEs cannot be used. + </para> + </listitem> + + <listitem> + <para> + Window functions cannot be used. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s must be based on simple base tables. It's not + supported to create them on top of views, materialized views, foreign tables, inhe. + </para> + </listitem> + + <listitem> + <para> + LIMIT and OFFSET clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s cannot contain system columns. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s cannot contain non-immutable functions. + </para> + </listitem> + + <listitem> + <para> + UNION/INTERSECT/EXCEPT clauses cannnot be used. + </para> + </listitem> + + <listitem> + <para> + DISTINCT ON clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + TABLESAMPLE parameter cannot be used. + </para> + </listitem> + + <listitem> + <para> + inheritance parent tables cannnot be used. + </para> + </listitem> + + <listitem> + <para> + VALUES clause cannnot be used. + </para> + </listitem> + + <listitem> + <para> + <literal>GROUPING SETS</literal> and <literal>FILTER</literal> clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + FOR UPDATE/SHARE cannot be used. + </para> + </listitem> + + <listitem> + <para> + targetlist cannot contain columns whose name start with <literal>__ivm_</literal>. + </para> + </listitem> + + <listitem> + <para> + targetlist cannot contain expressions which contain an aggregate in it. + </para> + </listitem> + + <listitem> + <para> + Logical replication is not supported, that is, even when a base table + at a publisher node is modified, <acronym>IMMV</acronym>s at subscriber + nodes are not updated. + </para> + </listitem> + + <listitem> + <para> + When the <literal>TRUNCATE</literal> command is executed on a base table, + nothing is changed on the <acronym>IMMV</acronym>. + </para> + </listitem> + + </itemizedlist> +</para> +</sect3> + +</sect2> + +<sect2> +<title><literal>DISTINCT</literal></title> + +<para> + <productname>PostgreSQL</productname> supports <acronym>IMMV</acronym> with + <literal>DISTINCT</literal>. For example, suppose a <acronym>IMMV</acronym> + defined with <literal>DISTINCT</literal> 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. +</para> + +<para> + Physically, an <acronym>IMMV</acronym> defined with <literal>DISTINCT</literal> + contains tuples after eliminating duplicates, and the multiplicity of each tuple + is stored in a hidden column named <literal>__ivm_count__</literal>. +</para> +</sect2> + +<sect2> +<title>Concurrent Transactions</title> +<para> + Suppose an <acronym>IMMV</acronym> is defined on two base tables and each + table was modified in different a concurrent transaction simultaneously. + In the transaction which was committed first, <acronym>IMMV</acronym> 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, <literal>ExclusiveLock</literal> + is held on an <acronym>IMMV</acronym> immediately after a base table is + modified in <literal>READ COMMITTED</literal> mode to make sure that + the <acronym>IMMV</acronym> is updated in the latter transaction after + the former transaction is committed. In <literal>REPEATABLE READ</literal> + or <literal>SERIALIZABLE</literal> 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 + <acronym>IMMV</acronym> cannot be updated correctly in such situations. + However, as an exception if the view has only one base table, + the lock held on thew view is <literal>RowExclusiveLock</literal>. +</para> +</sect2> + +<sect2> +<title>Row Level Security</title> +<para> + 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. +</para> +</sect2> + +</sect1> + <sect1 id="rules-update"> <title>Rules on <command>INSERT</command>, <command>UPDATE</command>, and <command>DELETE</command></title> -- 2.17.1 --Multipart=_Fri__4_Feb_2022_01_48_06_+0900_N8BNZpfOR27sWrgY Content-Type: text/x-diff; name="v25-0009-Add-regression-tests-for-Incremental-View-Mainte.patch" Content-Disposition: attachment; filename="v25-0009-Add-regression-tests-for-Incremental-View-Mainte.patch" Content-Transfer-Encoding: 7bit ^ permalink raw reply [nested|flat] 22+ messages in thread
* [PATCH v26 10/10] Add documentations about Incremental View Maintenance @ 2019-12-20 01:25 Yugo Nagata <[email protected]> 0 siblings, 0 replies; 22+ messages in thread From: Yugo Nagata @ 2019-12-20 01:25 UTC (permalink / raw) --- doc/src/sgml/catalogs.sgml | 24 +- .../sgml/ref/create_materialized_view.sgml | 131 +++++- .../sgml/ref/refresh_materialized_view.sgml | 8 +- doc/src/sgml/rules.sgml | 443 ++++++++++++++++++ 4 files changed, 601 insertions(+), 5 deletions(-) diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml index 7777d60514..990798e13d 100644 --- a/doc/src/sgml/catalogs.sgml +++ b/doc/src/sgml/catalogs.sgml @@ -2188,6 +2188,15 @@ SCRAM-SHA-256$<replaceable><iteration count></replaceable>:<replaceable>&l </para></entry> </row> + <row> + <entry role="catalog_table_entry"><para role="column_definition"> + <structfield>relisivm</structfield> <type>bool</type> + </para> + <para> + True if materialized view enables incremental view maintenance + </para></entry> + </row> + <row> <entry role="catalog_table_entry"><para role="column_definition"> <structfield>relrewrite</structfield> <type>oid</type> @@ -3485,6 +3494,18 @@ SCRAM-SHA-256$<replaceable><iteration count></replaceable>:<replaceable>&l </para> </listitem> </varlistentry> + + <varlistentry> + <term><symbol>DEPENDENCY_IMMV</symbol> (<literal>m</literal>)</term> + <listitem> + <para> + The dependent object was created as part of creation of the Materialized + View with Incremental View Maintenance reference, and is really just a + part of its internal implementation. The dependent object must not be + dropped unless the materialized view is also dropped. + </para> + </listitem> + </varlistentry> </variablelist> Other dependency flavors might be needed in future. @@ -3868,7 +3889,8 @@ SCRAM-SHA-256$<replaceable><iteration count></replaceable>:<replaceable>&l <structfield>extrelocatable</structfield> <type>bool</type> </para> <para> - True if extension can be relocated to another schema + True for materialized views which are enabled for incremental + view maintenance (IVM). </para></entry> </row> diff --git a/doc/src/sgml/ref/create_materialized_view.sgml b/doc/src/sgml/ref/create_materialized_view.sgml index 0d2fea2b97..52a4d206b1 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 <refsynopsisdiv> <synopsis> -CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> +CREATE [ INCREMENTAL ] MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> [ (<replaceable>column_name</replaceable> [, ...] ) ] [ USING <replaceable class="parameter">method</replaceable> ] [ WITH ( <replaceable class="parameter">storage_parameter</replaceable> [= <replaceable class="parameter">value</replaceable>] [, ... ] ) ] @@ -60,6 +60,132 @@ CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> <title>Parameters</title> <variablelist> + <varlistentry> + <term><literal>INCREMENTAL</literal></term> + <listitem> + <para> + 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). + </para> + <para> + When <acronym>IMMV</acronym> is defined without using <command>WITH NO DATA</command>, + 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. + </para> + <para> + There are restrictions of query definitions allowed to use this + option. The following are supported in query definitions for IMMV: + <itemizedlist> + + <listitem> + <para> + Inner joins (including self-joins). + </para> + </listitem> + + <listitem> + <para> + Some built-in aggregate functions (count, sum, avg, min, max) without a HAVING + clause. + </para> + </listitem> + </itemizedlist> + + Unsupported queries with this option include the following: + + <itemizedlist> + <listitem> + <para> + Outer joins. + </para> + </listitem> + + <listitem> + <para> + Sub-queries. + </para> + </listitem> + + <listitem> + <para> + Aggregate functions other than built-in count, sum, avg, min and max. + </para> + </listitem> + <listitem> + <para> + Aggregate functions with a HAVING clause. + </para> + </listitem> + <listitem> + <para> + DISTINCT ON, WINDOW, VALUES, LIMIT and OFFSET clause. + </para> + </listitem> + </itemizedlist> + + Other restrictions include: + <itemizedlist> + + <listitem> + <para> + IMMVs must be based on simple base tables. It's not supported to + create them on top of views or materialized views. + </para> + </listitem> + + <listitem> + <para> + When the TRUNCATE command is executed on a base table, + no changes are made to the materialized view. + </para> + </listitem> + + <listitem> + <para> + It is not supported to include system columns in an IMMV. + <programlisting> +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 + </programlisting> + </para> + </listitem> + + <listitem> + <para> + Non-immutable functions are not supported. + <programlisting> +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 + </programlisting> + </para> + </listitem> + + <listitem> + <para> + IMMVs do not support expressions that contains aggregates + </para> + </listitem> + + <listitem> + <para> + Logical replication does not support IMMVs. + </para> + </listitem> + + </itemizedlist> + + </para> + </listitem> + </varlistentry> + <varlistentry> <term><literal>IF NOT EXISTS</literal></term> <listitem> @@ -155,7 +281,8 @@ CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> 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 <command>REFRESH - MATERIALIZED VIEW</command> is used. + MATERIALIZED VIEW</command> is used. Also, if the view is IMMV, + triggers for maintaining the view are not created. </para> </listitem> </varlistentry> 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 ] <replaceable class="parameter">name</ owner of the materialized view. The old contents are discarded. If <literal>WITH DATA</literal> 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 <literal>WITH NO DATA</literal> 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 <literal>WITH NO DATA</literal> 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. </para> <para> <literal>CONCURRENTLY</literal> and <literal>WITH NO DATA</literal> may not diff --git a/doc/src/sgml/rules.sgml b/doc/src/sgml/rules.sgml index 4aa4e00e01..13a64eab7f 100644 --- a/doc/src/sgml/rules.sgml +++ b/doc/src/sgml/rules.sgml @@ -1090,6 +1090,449 @@ SELECT word FROM words ORDER BY word <-> 'caterpiler' LIMIT 10; </sect1> +<sect1 id="rules-ivm"> +<title>Incremental View Maintenance</title> + +<indexterm zone="rules-ivm"> + <primary>incremental view maintenance</primary> +</indexterm> + +<indexterm zone="rules-ivm"> + <primary>materialized view</primary> + <secondary>incremental view maintenance</secondary> +</indexterm> + +<indexterm zone="rules-ivm"> + <primary>view</primary> + <secondary>incremental view maintenance</secondary> +</indexterm> + +<sect2 id="rules-ivm-overview"> +<title>Overview</title> + +<para> + Incremental View Maintenance (<acronym>IVM</acronym>) 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 + <command>REFRESH MATERIALIZED VIEW</command> does. <acronym>IVM</acronym> + can update materialized views more efficiently than recomputation when only + small parts of the view are changed. +</para> + +<para> + 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 <command>REFRESH + MATERIALIZED VIEW</command>, or periodically in background, and so on. + <productname>PostgreSQL</productname> currently implements only a kind of + immediate maintenance, in which materialized views are updated immediately + in AFTER triggers when a base table is modified. +</para> + +<para> + To create materialized views supporting <acronym>IVM</acronym>, use the + <command>CREATE INCREMENTAL MATERIALIZED VIEW</command>, for example: +<programlisting> +CREATE <emphasis>INCREMENTAL</emphasis> MATERIALIZED VIEW mymatview AS SELECT * FROM mytab; +</programlisting> + When a materialized view is created with the <literal>INCREMENTAL</literal> + 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 + (<acronym>IMMV</acronym>). +<programlisting> +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) +</programlisting> +</para> + +<para> + Some <acronym>IMMV</acronym>s have hidden columns which are added + automatically when a materialized view is created. Their name starts + with <literal>__ivm_</literal> and they contain information required + for maintaining the <acronym>IMMV</acronym>. Such columns are not visible + when the <acronym>IMMV</acronym> is accessed by <literal>SELECT *</literal> + but are visible if the column name is explicitly specified in the target + list. We can also see the hidden columns in <literal>\d</literal> + meta-commands of <command>psql</command> commands. +</para> + +<para> + In general, <acronym>IMMV</acronym>s allow faster updates of materialized + views at the price of slower updates to their base tables. Updates of + <acronym>IMMV</acronym> is slower because triggers will be invoked and the + view is updated in triggers per modification statement. +</para> + +<para> + For example, suppose a normal materialized view defined as below: + +<programlisting> +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 + +</programlisting> + + Updating a tuple in a base table of this materialized view is rapid but the + <command>REFRESH MATERIALIZED VIEW</command> command on this view takes a long time: + +<programlisting> +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) +</programlisting> +</para> + +<para> + On the other hand, after creating <acronym>IMMV</acronym> with the same view + definition as below: + +<programlisting> +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" +</programlisting> + + 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 + <command>REFRESH MATERIALIZED VIEW</command> command. + +<programlisting> +test=# UPDATE pgbench_accounts SET abalance = 1000 WHERE aid = 1; +UPDATE 1 +Time: 13.068 ms +</programlisting> + +</para> + +<para> + Appropriate indexes on <acronym>IMMV</acronym>s are necessary for + efficient <acronym>IVM</acronym> because it looks for tuples to be + updated in <acronym>IMMV</acronym>. If there are no indexes, it + will take a long time. +</para> + +<para> + Therefore, when <acronym>IMMV</acronym> 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. +</para> + +<para> + 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. +<programlisting> +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) +</programlisting> + +</para> + +<para> + <acronym>IVM</acronym> 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, <acronym>IVM</acronym> + 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, <acronym>IVM</acronym> is not effective and the cost of + maintenance can be larger than the <command>REFRESH MATERIALIZED VIEW</command> + command. In such situation, we can use <command>REFRESH MATERIALIZED VIEW</command> + and specify <literal>WITH NO DATA</literal> to disable immediate + maintenance before modifying a base table. After a base table modification, + execute the <command>REFRESH MATERIALIZED VIEW</command> (with <literal>WITH DATA</literal>) + command to refresh the view data and enable immediate maintenance. +</para> + +</sect2> + +<sect2> +<title>Supported View Definitions and Restrictions</title> + +<para> + Currently, we can create <acronym>IMMV</acronym>s using inner joins, and some + aggregates. However, several restrictions apply to the definition of IMMV. +</para> + +<sect3> +<title>Joins</title> +<para> + Inner joins including self-join are supported. Outer joins are not supported. +</para> +</sect3> + +<sect3> +<title>Aggregates</title> +<para> + Supported aggregate functions are <function>count</function>, <function>sum</function>, + <function>avg</function>, <function>min</function>, and <function>max</function>. + 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 <acronym>IMMV</acronym>. +</para> + +<para> + Note that for <function>min</function> or <function>max</function>, 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 <acronym>IMMV</acronym> containing + these functions. +</para> + +<para> + Also note that using <function>sum</function> or <function>avg</function> on + <type>real</type> (<type>float4</type>) type or <type>double precision</type> + (<type>float8</type>) type in <acronym>IMMV</acronym> is unsafe. This is + because aggregated values in <acronym>IMMV</acronym> can become different from + results calculated from base tables due to the limited precision of these types. + To avoid this problem, use the <type>numeric</type> type instead. +</para> + + <sect4> + <title>Restrictions on Aggregates</title> + <para> + There are the following restrictions: + <itemizedlist> + <listitem> + <para> + If we have a <literal>GROUP BY</literal> clause, expressions specified in + <literal>GROUP BY</literal> must appear in the target list. This is + how tuples to be updated in the <acronym>IMMV</acronym> are identified. + These attributes are used as scan keys for searching tuples in the + <acronym>IMMV</acronym>, so indexes on them are required for efficient + <acronym>IVM</acronym>. + </para> + </listitem> + + <listitem> + <para> + <literal>HAVING</literal> clause cannot be used. + </para> + </listitem> + </itemizedlist> + </para> + </sect4> +</sect3> + +<sect3> +<title>Other General Restrictions</title> +<para> + There are other restrictions which generally apply to <acronym>IMMV</acronym>: + <itemizedlist> + <listitem> + <para> + Sub-queries cannot be used. + </para> + </listitem> + + <listitem> + <para> + CTEs cannot be used. + </para> + </listitem> + + <listitem> + <para> + Window functions cannot be used. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s must be based on simple base tables. It's not + supported to create them on top of views, materialized views, foreign tables, inhe. + </para> + </listitem> + + <listitem> + <para> + LIMIT and OFFSET clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s cannot contain system columns. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s cannot contain non-immutable functions. + </para> + </listitem> + + <listitem> + <para> + UNION/INTERSECT/EXCEPT clauses cannnot be used. + </para> + </listitem> + + <listitem> + <para> + DISTINCT ON clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + TABLESAMPLE parameter cannot be used. + </para> + </listitem> + + <listitem> + <para> + inheritance parent tables cannnot be used. + </para> + </listitem> + + <listitem> + <para> + VALUES clause cannnot be used. + </para> + </listitem> + + <listitem> + <para> + <literal>GROUPING SETS</literal> and <literal>FILTER</literal> clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + FOR UPDATE/SHARE cannot be used. + </para> + </listitem> + + <listitem> + <para> + targetlist cannot contain columns whose name start with <literal>__ivm_</literal>. + </para> + </listitem> + + <listitem> + <para> + targetlist cannot contain expressions which contain an aggregate in it. + </para> + </listitem> + + <listitem> + <para> + Logical replication is not supported, that is, even when a base table + at a publisher node is modified, <acronym>IMMV</acronym>s at subscriber + nodes are not updated. + </para> + </listitem> + + <listitem> + <para> + When the <literal>TRUNCATE</literal> command is executed on a base table, + nothing is changed on the <acronym>IMMV</acronym>. + </para> + </listitem> + + </itemizedlist> +</para> +</sect3> + +</sect2> + +<sect2> +<title><literal>DISTINCT</literal></title> + +<para> + <productname>PostgreSQL</productname> supports <acronym>IMMV</acronym> with + <literal>DISTINCT</literal>. For example, suppose a <acronym>IMMV</acronym> + defined with <literal>DISTINCT</literal> 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. +</para> + +<para> + Physically, an <acronym>IMMV</acronym> defined with <literal>DISTINCT</literal> + contains tuples after eliminating duplicates, and the multiplicity of each tuple + is stored in a hidden column named <literal>__ivm_count__</literal>. +</para> +</sect2> + +<sect2> +<title>Concurrent Transactions</title> +<para> + Suppose an <acronym>IMMV</acronym> is defined on two base tables and each + table was modified in different a concurrent transaction simultaneously. + In the transaction which was committed first, <acronym>IMMV</acronym> 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, <literal>ExclusiveLock</literal> + is held on an <acronym>IMMV</acronym> immediately after a base table is + modified in <literal>READ COMMITTED</literal> mode to make sure that + the <acronym>IMMV</acronym> is updated in the latter transaction after + the former transaction is committed. In <literal>REPEATABLE READ</literal> + or <literal>SERIALIZABLE</literal> 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 + <acronym>IMMV</acronym> cannot be updated correctly in such situations. + However, as an exception if the view has only one base table, + the lock held on thew view is <literal>RowExclusiveLock</literal>. +</para> +</sect2> + +<sect2> +<title>Row Level Security</title> +<para> + 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. +</para> +</sect2> + +</sect1> + <sect1 id="rules-update"> <title>Rules on <command>INSERT</command>, <command>UPDATE</command>, and <command>DELETE</command></title> -- 2.17.1 --Multipart=_Mon__14_Mar_2022_19_12_17_+0900_E9HVp8j5QFkIIek. Content-Type: text/x-diff; name="v26-0009-Add-regression-tests-for-Incremental-View-Mainte.patch" Content-Disposition: attachment; filename="v26-0009-Add-regression-tests-for-Incremental-View-Mainte.patch" Content-Transfer-Encoding: 7bit ^ permalink raw reply [nested|flat] 22+ messages in thread
* [PATCH v24 10/15] Add documentations about Incremental View Maintenance @ 2019-12-20 01:25 Yugo Nagata <[email protected]> 0 siblings, 0 replies; 22+ messages in thread From: Yugo Nagata @ 2019-12-20 01:25 UTC (permalink / raw) --- doc/src/sgml/catalogs.sgml | 24 +- .../sgml/ref/create_materialized_view.sgml | 131 +++++- .../sgml/ref/refresh_materialized_view.sgml | 6 +- doc/src/sgml/rules.sgml | 443 ++++++++++++++++++ 4 files changed, 599 insertions(+), 5 deletions(-) diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml index 00b648a433..68a1377b6f 100644 --- a/doc/src/sgml/catalogs.sgml +++ b/doc/src/sgml/catalogs.sgml @@ -2188,6 +2188,15 @@ SCRAM-SHA-256$<replaceable><iteration count></replaceable>:<replaceable>&l </para></entry> </row> + <row> + <entry role="catalog_table_entry"><para role="column_definition"> + <structfield>relisivm</structfield> <type>bool</type> + </para> + <para> + True if materialized view enables incremental view maintenance + </para></entry> + </row> + <row> <entry role="catalog_table_entry"><para role="column_definition"> <structfield>relrewrite</structfield> <type>oid</type> @@ -3472,6 +3481,18 @@ SCRAM-SHA-256$<replaceable><iteration count></replaceable>:<replaceable>&l </para> </listitem> </varlistentry> + + <varlistentry> + <term><symbol>DEPENDENCY_IMMV</symbol> (<literal>m</literal>)</term> + <listitem> + <para> + The dependent object was created as part of creation of the Materialized + View with Incremental View Maintenance reference, and is really just a + part of its internal implementation. The dependent object must not be + dropped unless the materialized view is also dropped. + </para> + </listitem> + </varlistentry> </variablelist> Other dependency flavors might be needed in future. @@ -3855,7 +3876,8 @@ SCRAM-SHA-256$<replaceable><iteration count></replaceable>:<replaceable>&l <structfield>extrelocatable</structfield> <type>bool</type> </para> <para> - True if extension can be relocated to another schema + True for materialized views which are enabled for incremental + view maintenance (IVM). </para></entry> </row> diff --git a/doc/src/sgml/ref/create_materialized_view.sgml b/doc/src/sgml/ref/create_materialized_view.sgml index d8c48252f4..8a440ca810 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 <refsynopsisdiv> <synopsis> -CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> +CREATE [ INCREMENTAL ] MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> [ (<replaceable>column_name</replaceable> [, ...] ) ] [ USING <replaceable class="parameter">method</replaceable> ] [ WITH ( <replaceable class="parameter">storage_parameter</replaceable> [= <replaceable class="parameter">value</replaceable>] [, ... ] ) ] @@ -60,6 +60,132 @@ CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> <title>Parameters</title> <variablelist> + <varlistentry> + <term><literal>INCREMENTAL</literal></term> + <listitem> + <para> + 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). + </para> + <para> + When <acronym>IMMV</acronym> 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. + </para> + <para> + There are restrictions of query definitions allowed to use this + option. The following are supported in query definitions for IMMV: + <itemizedlist> + + <listitem> + <para> + Inner joins (including self-joins). + </para> + </listitem> + + <listitem> + <para> + Some built-in aggregate functions (count, sum, avg, min, max) without a HAVING + clause. + </para> + </listitem> + </itemizedlist> + + Unsupported queries with this option include the following: + + <itemizedlist> + <listitem> + <para> + Outer joins. + </para> + </listitem> + + <listitem> + <para> + Sub-queries. + </para> + </listitem> + + <listitem> + <para> + Aggregate functions other than built-in count, sum, avg, min and max. + </para> + </listitem> + <listitem> + <para> + Aggregate functions with a HAVING clause. + </para> + </listitem> + <listitem> + <para> + DISTINCT ON, WINDOW, VALUES, LIMIT and OFFSET clause. + </para> + </listitem> + </itemizedlist> + + Other restrictions include: + <itemizedlist> + + <listitem> + <para> + IMMVs must be based on simple base tables. It's not supported to + create them on top of views or materialized views. + </para> + </listitem> + + <listitem> + <para> + When the TRUNCATE command is executed on a base table, + no changes are made to the materialized view. + </para> + </listitem> + + <listitem> + <para> + It is not supported to include system columns in an IMMV. + <programlisting> +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 + </programlisting> + </para> + </listitem> + + <listitem> + <para> + Non-immutable functions are not supported. + <programlisting> +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 + </programlisting> + </para> + </listitem> + + <listitem> + <para> + IMMVs do not support expressions that contains aggregates + </para> + </listitem> + + <listitem> + <para> + Logical replication does not support IMMVs. + </para> + </listitem> + + </itemizedlist> + + </para> + </listitem> + </varlistentry> + <varlistentry> <term><literal>IF NOT EXISTS</literal></term> <listitem> @@ -153,7 +279,8 @@ CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> 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 <command>REFRESH - MATERIALIZED VIEW</command> is used. + MATERIALIZED VIEW</command> is used. Also, if the view is IMMV, + triggers for maintaining the view are not created. </para> </listitem> </varlistentry> diff --git a/doc/src/sgml/ref/refresh_materialized_view.sgml b/doc/src/sgml/ref/refresh_materialized_view.sgml index 3bf8884447..dc81853057 100644 --- a/doc/src/sgml/ref/refresh_materialized_view.sgml +++ b/doc/src/sgml/ref/refresh_materialized_view.sgml @@ -35,9 +35,11 @@ REFRESH MATERIALIZED VIEW [ CONCURRENTLY ] <replaceable class="parameter">name</ owner of the materialized view. The old contents are discarded. If <literal>WITH DATA</literal> 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 <literal>WITH NO DATA</literal> is specified no new + scannable state. Also, if the view is an incrementally maintainable materialized + view (IMMV) and was unpopulated, triggers for maintaining + the view are created. If <literal>WITH NO DATA</literal> 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. </para> <para> <literal>CONCURRENTLY</literal> and <literal>WITH NO DATA</literal> may not diff --git a/doc/src/sgml/rules.sgml b/doc/src/sgml/rules.sgml index 6065b1c2a3..264fdefc37 100644 --- a/doc/src/sgml/rules.sgml +++ b/doc/src/sgml/rules.sgml @@ -1093,6 +1093,449 @@ SELECT word FROM words ORDER BY word <-> 'caterpiler' LIMIT 10; </sect1> +<sect1 id="rules-ivm"> +<title>Incremental View Maintenance</title> + +<indexterm zone="rules-ivm"> + <primary>incremental view maintenance</primary> +</indexterm> + +<indexterm zone="rules-ivm"> + <primary>materialized view</primary> + <secondary>incremental view maintenance</secondary> +</indexterm> + +<indexterm zone="rules-ivm"> + <primary>view</primary> + <secondary>incremental view maintenance</secondary> +</indexterm> + +<sect2 id="rules-ivm-overview"> +<title>Overview</title> + +<para> + Incremental View Maintenance (<acronym>IVM</acronym>) 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 + <command>REFRESH MATERIALIZED VIEW</command> does. <acronym>IVM</acronym> + can update materialized views more efficiently than recomputation when only + small parts of the view are changed. +</para> + +<para> + 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 <command>REFRESH + MATERIALIZED VIEW</command>, or periodically in background, and so on. + <productname>PostgreSQL</productname> currently implements only a kind of + immediate maintenance, in which materialized views are updated immediately + in AFTER triggers when a base table is modified. +</para> + +<para> + To create materialized views supporting <acronym>IVM</acronym>, use the + <command>CREATE INCREMENTAL MATERIALIZED VIEW</command>, for example: +<programlisting> +CREATE <emphasis>INCREMENTAL</emphasis> MATERIALIZED VIEW mymatview AS SELECT * FROM mytab; +</programlisting> + When a materialized view is created with the <literal>INCREMENTAL</literal> + 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 + (<acronym>IMMV</acronym>). +<programlisting> +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) +</programlisting> +</para> + +<para> + Some <acronym>IMMV</acronym>s have hidden columns which are added + automatically when a materialized view is created. Their name starts + with <literal>__ivm_</literal> and they contain information required + for maintaining the <acronym>IMMV</acronym>. Such columns are not visible + when the <acronym>IMMV</acronym> is accessed by <literal>SELECT *</literal> + but are visible if the column name is explicitly specified in the target + list. We can also see the hidden columns in <literal>\d</literal> + meta-commands of <command>psql</command> commands. +</para> + +<para> + In general, <acronym>IMMV</acronym>s allow faster updates of materialized + views at the price of slower updates to their base tables. Updates of + <acronym>IMMV</acronym> is slower because triggers will be invoked and the + view is updated in triggers per modification statement. +</para> + +<para> + For example, suppose a normal materialized view defined as below: + +<programlisting> +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 + +</programlisting> + + Updating a tuple in a base table of this materialized view is rapid but the + <command>REFRESH MATERIALIZED VIEW</command> command on this view takes a long time: + +<programlisting> +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) +</programlisting> +</para> + +<para> + On the other hand, after creating <acronym>IMMV</acronym> with the same view + definition as below: + +<programlisting> +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" +</programlisting> + + 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 + <command>REFRESH MATERIALIZED VIEW</command> command. + +<programlisting> +test=# UPDATE pgbench_accounts SET abalance = 1000 WHERE aid = 1; +UPDATE 1 +Time: 13.068 ms +</programlisting> + +</para> + +<para> + Appropriate indexes on <acronym>IMMV</acronym>s are necessary for + efficient <acronym>IVM</acronym> because it looks for tuples to be + updated in <acronym>IMMV</acronym>. If there are no indexes, it + will take a long time. +</para> + +<para> + Therefore, when <acronym>IMMV</acronym> 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. +</para> + +<para> + 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. +<programlisting> +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) +</programlisting> + +</para> + +<para> + <acronym>IVM</acronym> 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, <acronym>IVM</acronym> + 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, <acronym>IVM</acronym> is not effective and the cost of + maintenance can be larger than the <command>REFRESH MATERIALIZED VIEW</command> + command. In such situation, we can use <command>REFRESH MATERIALIZED VIEW</command> + and specify <literal>WITH NO DATA</literal> to disable immediate + maintenance before modifying a base table. After a base table modification, + execute the <command>REFRESH MATERIALIZED VIEW</command> (with <literal>WITH DATA</literal>) + command to refresh the view data and enable immediate maintenance. +</para> + +</sect2> + +<sect2> +<title>Supported View Definitions and Restrictions</title> + +<para> + Currently, we can create <acronym>IMMV</acronym>s using inner joins, and some + aggregates. However, several restrictions apply to the definition of IMMV. +</para> + +<sect3> +<title>Joins</title> +<para> + Inner joins including self-join are supported. Outer joins are not supported. +</para> +</sect3> + +<sect3> +<title>Aggregates</title> +<para> + Supported aggregate functions are <function>count</function>, <function>sum</function>, + <function>avg</function>, <function>min</function>, and <function>max</function>. + 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 <acronym>IMMV</acronym>. +</para> + +<para> + Note that for <function>min</function> or <function>max</function>, 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 <acronym>IMMV</acronym> containing + these functions. +</para> + +<para> + Also note that using <function>sum</function> or <function>avg</function> on + <type>real</type> (<type>float4</type>) type or <type>double precision</type> + (<type>float8</type>) type in <acronym>IMMV</acronym> is unsafe. This is + because aggregated values in <acronym>IMMV</acronym> can become different from + results calculated from base tables due to the limited precision of these types. + To avoid this problem, use the <type>numeric</type> type instead. +</para> + + <sect4> + <title>Restrictions on Aggregates</title> + <para> + There are the following restrictions: + <itemizedlist> + <listitem> + <para> + If we have a <literal>GROUP BY</literal> clause, expressions specified in + <literal>GROUP BY</literal> must appear in the target list. This is + how tuples to be updated in the <acronym>IMMV</acronym> are identified. + These attributes are used as scan keys for searching tuples in the + <acronym>IMMV</acronym>, so indexes on them are required for efficient + <acronym>IVM</acronym>. + </para> + </listitem> + + <listitem> + <para> + <literal>HAVING</literal> clause cannot be used. + </para> + </listitem> + </itemizedlist> + </para> + </sect4> +</sect3> + +<sect3> +<title>Other General Restrictions</title> +<para> + There are other restrictions which generally apply to <acronym>IMMV</acronym>: + <itemizedlist> + <listitem> + <para> + Sub-queries cannot be used. + </para> + </listitem> + + <listitem> + <para> + CTEs cannot be used. + </para> + </listitem> + + <listitem> + <para> + Window functions cannot be used. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s must be based on simple base tables. It's not + supported to create them on top of views or materialized views. + </para> + </listitem> + + <listitem> + <para> + LIMIT and OFFSET clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s cannot contain system columns. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s cannot contain non-immutable functions. + </para> + </listitem> + + <listitem> + <para> + UNION/INTERSECT/EXCEPT clauses cannnot be used. + </para> + </listitem> + + <listitem> + <para> + DISTINCT ON clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + TABLESAMPLE parameter cannot be used. + </para> + </listitem> + + <listitem> + <para> + inheritance parent tables cannnot be used. + </para> + </listitem> + + <listitem> + <para> + VALUES clause cannnot be used. + </para> + </listitem> + + <listitem> + <para> + <literal>GROUPING SETS</literal> and <literal>FILTER</literal> clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + FOR UPDATE/SHARE cannot be used. + </para> + </listitem> + + <listitem> + <para> + targetlist cannot contain columns whose name start with <literal>__ivm_</literal>. + </para> + </listitem> + + <listitem> + <para> + targetlist cannot contain expressions which contain an aggregate in it. + </para> + </listitem> + + <listitem> + <para> + Logical replication is not supported, that is, even when a base table + at a publisher node is modified, <acronym>IMMV</acronym>s at subscriber + nodes are not updated. + </para> + </listitem> + + <listitem> + <para> + When the <literal>TRUNCATE</literal> command is executed on a base table, + nothing is changed on the <acronym>IMMV</acronym>. + </para> + </listitem> + + </itemizedlist> +</para> +</sect3> + +</sect2> + +<sect2> +<title><literal>DISTINCT</literal></title> + +<para> + <productname>PostgreSQL</productname> supports <acronym>IMMV</acronym> with + <literal>DISTINCT</literal>. For example, suppose a <acronym>IMMV</acronym> + defined with <literal>DISTINCT</literal> 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. +</para> + +<para> + Physically, an <acronym>IMMV</acronym> defined with <literal>DISTINCT</literal> + contains tuples after eliminating duplicates, and the multiplicity of each tuple + is stored in a hidden column named <literal>__ivm_count__</literal>. +</para> +</sect2> + +<sect2> +<title>Concurrent Transactions</title> +<para> + Suppose an <acronym>IMMV</acronym> is defined on two base tables and each + table was modified in different a concurrent transaction simultaneously. + In the transaction which was committed first, <acronym>IMMV</acronym> 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, <literal>ExclusiveLock</literal> + is held on an <acronym>IMMV</acronym> immediately after a base table is + modified in <literal>READ COMMITTED</literal> mode to make sure that + the <acronym>IMMV</acronym> is updated in the latter transaction after + the former transaction is committed. In <literal>REPEATABLE READ</literal> + or <literal>SERIALIZABLE</literal> 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 + <acronym>IMMV</acronym> cannot be updated correctly in such situations. + However, as an exception if the view has only one base table, + the lock held on thew view is <literal>RowExclusiveLock</literal>. +</para> +</sect2> + +<sect2> +<title>Row Level Security</title> +<para> + 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. +</para> +</sect2> + +</sect1> + <sect1 id="rules-update"> <title>Rules on <command>INSERT</command>, <command>UPDATE</command>, and <command>DELETE</command></title> -- 2.17.1 --Multipart=_Fri__29_Oct_2021_18_16_28_+0900_jlYRKjywLqhZ7oyk-- ^ permalink raw reply [nested|flat] 22+ messages in thread
* [PATCH v24 10/15] Add documentations about Incremental View Maintenance @ 2019-12-20 01:25 Yugo Nagata <[email protected]> 0 siblings, 0 replies; 22+ messages in thread From: Yugo Nagata @ 2019-12-20 01:25 UTC (permalink / raw) --- doc/src/sgml/catalogs.sgml | 24 +- .../sgml/ref/create_materialized_view.sgml | 131 +++++- .../sgml/ref/refresh_materialized_view.sgml | 6 +- doc/src/sgml/rules.sgml | 443 ++++++++++++++++++ 4 files changed, 599 insertions(+), 5 deletions(-) diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml index 2f0def9b19..5d4d5a6e5e 100644 --- a/doc/src/sgml/catalogs.sgml +++ b/doc/src/sgml/catalogs.sgml @@ -2183,6 +2183,15 @@ SCRAM-SHA-256$<replaceable><iteration count></replaceable>:<replaceable>&l </para></entry> </row> + <row> + <entry role="catalog_table_entry"><para role="column_definition"> + <structfield>relisivm</structfield> <type>bool</type> + </para> + <para> + True if materialized view enables incremental view maintenance + </para></entry> + </row> + <row> <entry role="catalog_table_entry"><para role="column_definition"> <structfield>relrewrite</structfield> <type>oid</type> @@ -3465,6 +3474,18 @@ SCRAM-SHA-256$<replaceable><iteration count></replaceable>:<replaceable>&l </para> </listitem> </varlistentry> + + <varlistentry> + <term><symbol>DEPENDENCY_IMMV</symbol> (<literal>m</literal>)</term> + <listitem> + <para> + The dependent object was created as part of creation of the Materialized + View with Incremental View Maintenance reference, and is really just a + part of its internal implementation. The dependent object must not be + dropped unless the materialized view is also dropped. + </para> + </listitem> + </varlistentry> </variablelist> Other dependency flavors might be needed in future. @@ -3848,7 +3869,8 @@ SCRAM-SHA-256$<replaceable><iteration count></replaceable>:<replaceable>&l <structfield>extrelocatable</structfield> <type>bool</type> </para> <para> - True if extension can be relocated to another schema + True for materialized views which are enabled for incremental + view maintenance (IVM). </para></entry> </row> diff --git a/doc/src/sgml/ref/create_materialized_view.sgml b/doc/src/sgml/ref/create_materialized_view.sgml index d8c48252f4..8a440ca810 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 <refsynopsisdiv> <synopsis> -CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> +CREATE [ INCREMENTAL ] MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> [ (<replaceable>column_name</replaceable> [, ...] ) ] [ USING <replaceable class="parameter">method</replaceable> ] [ WITH ( <replaceable class="parameter">storage_parameter</replaceable> [= <replaceable class="parameter">value</replaceable>] [, ... ] ) ] @@ -60,6 +60,132 @@ CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> <title>Parameters</title> <variablelist> + <varlistentry> + <term><literal>INCREMENTAL</literal></term> + <listitem> + <para> + 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). + </para> + <para> + When <acronym>IMMV</acronym> 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. + </para> + <para> + There are restrictions of query definitions allowed to use this + option. The following are supported in query definitions for IMMV: + <itemizedlist> + + <listitem> + <para> + Inner joins (including self-joins). + </para> + </listitem> + + <listitem> + <para> + Some built-in aggregate functions (count, sum, avg, min, max) without a HAVING + clause. + </para> + </listitem> + </itemizedlist> + + Unsupported queries with this option include the following: + + <itemizedlist> + <listitem> + <para> + Outer joins. + </para> + </listitem> + + <listitem> + <para> + Sub-queries. + </para> + </listitem> + + <listitem> + <para> + Aggregate functions other than built-in count, sum, avg, min and max. + </para> + </listitem> + <listitem> + <para> + Aggregate functions with a HAVING clause. + </para> + </listitem> + <listitem> + <para> + DISTINCT ON, WINDOW, VALUES, LIMIT and OFFSET clause. + </para> + </listitem> + </itemizedlist> + + Other restrictions include: + <itemizedlist> + + <listitem> + <para> + IMMVs must be based on simple base tables. It's not supported to + create them on top of views or materialized views. + </para> + </listitem> + + <listitem> + <para> + When the TRUNCATE command is executed on a base table, + no changes are made to the materialized view. + </para> + </listitem> + + <listitem> + <para> + It is not supported to include system columns in an IMMV. + <programlisting> +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 + </programlisting> + </para> + </listitem> + + <listitem> + <para> + Non-immutable functions are not supported. + <programlisting> +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 + </programlisting> + </para> + </listitem> + + <listitem> + <para> + IMMVs do not support expressions that contains aggregates + </para> + </listitem> + + <listitem> + <para> + Logical replication does not support IMMVs. + </para> + </listitem> + + </itemizedlist> + + </para> + </listitem> + </varlistentry> + <varlistentry> <term><literal>IF NOT EXISTS</literal></term> <listitem> @@ -153,7 +279,8 @@ CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> 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 <command>REFRESH - MATERIALIZED VIEW</command> is used. + MATERIALIZED VIEW</command> is used. Also, if the view is IMMV, + triggers for maintaining the view are not created. </para> </listitem> </varlistentry> diff --git a/doc/src/sgml/ref/refresh_materialized_view.sgml b/doc/src/sgml/ref/refresh_materialized_view.sgml index 3bf8884447..dc81853057 100644 --- a/doc/src/sgml/ref/refresh_materialized_view.sgml +++ b/doc/src/sgml/ref/refresh_materialized_view.sgml @@ -35,9 +35,11 @@ REFRESH MATERIALIZED VIEW [ CONCURRENTLY ] <replaceable class="parameter">name</ owner of the materialized view. The old contents are discarded. If <literal>WITH DATA</literal> 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 <literal>WITH NO DATA</literal> is specified no new + scannable state. Also, if the view is an incrementally maintainable materialized + view (IMMV) and was unpopulated, triggers for maintaining + the view are created. If <literal>WITH NO DATA</literal> 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. </para> <para> <literal>CONCURRENTLY</literal> and <literal>WITH NO DATA</literal> may not diff --git a/doc/src/sgml/rules.sgml b/doc/src/sgml/rules.sgml index 6065b1c2a3..264fdefc37 100644 --- a/doc/src/sgml/rules.sgml +++ b/doc/src/sgml/rules.sgml @@ -1093,6 +1093,449 @@ SELECT word FROM words ORDER BY word <-> 'caterpiler' LIMIT 10; </sect1> +<sect1 id="rules-ivm"> +<title>Incremental View Maintenance</title> + +<indexterm zone="rules-ivm"> + <primary>incremental view maintenance</primary> +</indexterm> + +<indexterm zone="rules-ivm"> + <primary>materialized view</primary> + <secondary>incremental view maintenance</secondary> +</indexterm> + +<indexterm zone="rules-ivm"> + <primary>view</primary> + <secondary>incremental view maintenance</secondary> +</indexterm> + +<sect2 id="rules-ivm-overview"> +<title>Overview</title> + +<para> + Incremental View Maintenance (<acronym>IVM</acronym>) 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 + <command>REFRESH MATERIALIZED VIEW</command> does. <acronym>IVM</acronym> + can update materialized views more efficiently than recomputation when only + small parts of the view are changed. +</para> + +<para> + 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 <command>REFRESH + MATERIALIZED VIEW</command>, or periodically in background, and so on. + <productname>PostgreSQL</productname> currently implements only a kind of + immediate maintenance, in which materialized views are updated immediately + in AFTER triggers when a base table is modified. +</para> + +<para> + To create materialized views supporting <acronym>IVM</acronym>, use the + <command>CREATE INCREMENTAL MATERIALIZED VIEW</command>, for example: +<programlisting> +CREATE <emphasis>INCREMENTAL</emphasis> MATERIALIZED VIEW mymatview AS SELECT * FROM mytab; +</programlisting> + When a materialized view is created with the <literal>INCREMENTAL</literal> + 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 + (<acronym>IMMV</acronym>). +<programlisting> +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) +</programlisting> +</para> + +<para> + Some <acronym>IMMV</acronym>s have hidden columns which are added + automatically when a materialized view is created. Their name starts + with <literal>__ivm_</literal> and they contain information required + for maintaining the <acronym>IMMV</acronym>. Such columns are not visible + when the <acronym>IMMV</acronym> is accessed by <literal>SELECT *</literal> + but are visible if the column name is explicitly specified in the target + list. We can also see the hidden columns in <literal>\d</literal> + meta-commands of <command>psql</command> commands. +</para> + +<para> + In general, <acronym>IMMV</acronym>s allow faster updates of materialized + views at the price of slower updates to their base tables. Updates of + <acronym>IMMV</acronym> is slower because triggers will be invoked and the + view is updated in triggers per modification statement. +</para> + +<para> + For example, suppose a normal materialized view defined as below: + +<programlisting> +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 + +</programlisting> + + Updating a tuple in a base table of this materialized view is rapid but the + <command>REFRESH MATERIALIZED VIEW</command> command on this view takes a long time: + +<programlisting> +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) +</programlisting> +</para> + +<para> + On the other hand, after creating <acronym>IMMV</acronym> with the same view + definition as below: + +<programlisting> +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" +</programlisting> + + 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 + <command>REFRESH MATERIALIZED VIEW</command> command. + +<programlisting> +test=# UPDATE pgbench_accounts SET abalance = 1000 WHERE aid = 1; +UPDATE 1 +Time: 13.068 ms +</programlisting> + +</para> + +<para> + Appropriate indexes on <acronym>IMMV</acronym>s are necessary for + efficient <acronym>IVM</acronym> because it looks for tuples to be + updated in <acronym>IMMV</acronym>. If there are no indexes, it + will take a long time. +</para> + +<para> + Therefore, when <acronym>IMMV</acronym> 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. +</para> + +<para> + 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. +<programlisting> +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) +</programlisting> + +</para> + +<para> + <acronym>IVM</acronym> 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, <acronym>IVM</acronym> + 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, <acronym>IVM</acronym> is not effective and the cost of + maintenance can be larger than the <command>REFRESH MATERIALIZED VIEW</command> + command. In such situation, we can use <command>REFRESH MATERIALIZED VIEW</command> + and specify <literal>WITH NO DATA</literal> to disable immediate + maintenance before modifying a base table. After a base table modification, + execute the <command>REFRESH MATERIALIZED VIEW</command> (with <literal>WITH DATA</literal>) + command to refresh the view data and enable immediate maintenance. +</para> + +</sect2> + +<sect2> +<title>Supported View Definitions and Restrictions</title> + +<para> + Currently, we can create <acronym>IMMV</acronym>s using inner joins, and some + aggregates. However, several restrictions apply to the definition of IMMV. +</para> + +<sect3> +<title>Joins</title> +<para> + Inner joins including self-join are supported. Outer joins are not supported. +</para> +</sect3> + +<sect3> +<title>Aggregates</title> +<para> + Supported aggregate functions are <function>count</function>, <function>sum</function>, + <function>avg</function>, <function>min</function>, and <function>max</function>. + 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 <acronym>IMMV</acronym>. +</para> + +<para> + Note that for <function>min</function> or <function>max</function>, 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 <acronym>IMMV</acronym> containing + these functions. +</para> + +<para> + Also note that using <function>sum</function> or <function>avg</function> on + <type>real</type> (<type>float4</type>) type or <type>double precision</type> + (<type>float8</type>) type in <acronym>IMMV</acronym> is unsafe. This is + because aggregated values in <acronym>IMMV</acronym> can become different from + results calculated from base tables due to the limited precision of these types. + To avoid this problem, use the <type>numeric</type> type instead. +</para> + + <sect4> + <title>Restrictions on Aggregates</title> + <para> + There are the following restrictions: + <itemizedlist> + <listitem> + <para> + If we have a <literal>GROUP BY</literal> clause, expressions specified in + <literal>GROUP BY</literal> must appear in the target list. This is + how tuples to be updated in the <acronym>IMMV</acronym> are identified. + These attributes are used as scan keys for searching tuples in the + <acronym>IMMV</acronym>, so indexes on them are required for efficient + <acronym>IVM</acronym>. + </para> + </listitem> + + <listitem> + <para> + <literal>HAVING</literal> clause cannot be used. + </para> + </listitem> + </itemizedlist> + </para> + </sect4> +</sect3> + +<sect3> +<title>Other General Restrictions</title> +<para> + There are other restrictions which generally apply to <acronym>IMMV</acronym>: + <itemizedlist> + <listitem> + <para> + Sub-queries cannot be used. + </para> + </listitem> + + <listitem> + <para> + CTEs cannot be used. + </para> + </listitem> + + <listitem> + <para> + Window functions cannot be used. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s must be based on simple base tables. It's not + supported to create them on top of views or materialized views. + </para> + </listitem> + + <listitem> + <para> + LIMIT and OFFSET clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s cannot contain system columns. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s cannot contain non-immutable functions. + </para> + </listitem> + + <listitem> + <para> + UNION/INTERSECT/EXCEPT clauses cannnot be used. + </para> + </listitem> + + <listitem> + <para> + DISTINCT ON clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + TABLESAMPLE parameter cannot be used. + </para> + </listitem> + + <listitem> + <para> + inheritance parent tables cannnot be used. + </para> + </listitem> + + <listitem> + <para> + VALUES clause cannnot be used. + </para> + </listitem> + + <listitem> + <para> + <literal>GROUPING SETS</literal> and <literal>FILTER</literal> clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + FOR UPDATE/SHARE cannot be used. + </para> + </listitem> + + <listitem> + <para> + targetlist cannot contain columns whose name start with <literal>__ivm_</literal>. + </para> + </listitem> + + <listitem> + <para> + targetlist cannot contain expressions which contain an aggregate in it. + </para> + </listitem> + + <listitem> + <para> + Logical replication is not supported, that is, even when a base table + at a publisher node is modified, <acronym>IMMV</acronym>s at subscriber + nodes are not updated. + </para> + </listitem> + + <listitem> + <para> + When the <literal>TRUNCATE</literal> command is executed on a base table, + nothing is changed on the <acronym>IMMV</acronym>. + </para> + </listitem> + + </itemizedlist> +</para> +</sect3> + +</sect2> + +<sect2> +<title><literal>DISTINCT</literal></title> + +<para> + <productname>PostgreSQL</productname> supports <acronym>IMMV</acronym> with + <literal>DISTINCT</literal>. For example, suppose a <acronym>IMMV</acronym> + defined with <literal>DISTINCT</literal> 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. +</para> + +<para> + Physically, an <acronym>IMMV</acronym> defined with <literal>DISTINCT</literal> + contains tuples after eliminating duplicates, and the multiplicity of each tuple + is stored in a hidden column named <literal>__ivm_count__</literal>. +</para> +</sect2> + +<sect2> +<title>Concurrent Transactions</title> +<para> + Suppose an <acronym>IMMV</acronym> is defined on two base tables and each + table was modified in different a concurrent transaction simultaneously. + In the transaction which was committed first, <acronym>IMMV</acronym> 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, <literal>ExclusiveLock</literal> + is held on an <acronym>IMMV</acronym> immediately after a base table is + modified in <literal>READ COMMITTED</literal> mode to make sure that + the <acronym>IMMV</acronym> is updated in the latter transaction after + the former transaction is committed. In <literal>REPEATABLE READ</literal> + or <literal>SERIALIZABLE</literal> 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 + <acronym>IMMV</acronym> cannot be updated correctly in such situations. + However, as an exception if the view has only one base table, + the lock held on thew view is <literal>RowExclusiveLock</literal>. +</para> +</sect2> + +<sect2> +<title>Row Level Security</title> +<para> + 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. +</para> +</sect2> + +</sect1> + <sect1 id="rules-update"> <title>Rules on <command>INSERT</command>, <command>UPDATE</command>, and <command>DELETE</command></title> -- 2.17.1 --Multipart=_Thu__23_Sep_2021_04_57_30_+0900_b5pmgR1N8oMaMz.U-- ^ permalink raw reply [nested|flat] 22+ messages in thread
* [PATCH v23 10/15] Add documentations about Incremental View Maintenance @ 2019-12-20 01:25 Yugo Nagata <[email protected]> 0 siblings, 0 replies; 22+ messages in thread From: Yugo Nagata @ 2019-12-20 01:25 UTC (permalink / raw) --- doc/src/sgml/catalogs.sgml | 24 +- .../sgml/ref/create_materialized_view.sgml | 133 +++++- .../sgml/ref/refresh_materialized_view.sgml | 6 +- doc/src/sgml/rules.sgml | 443 ++++++++++++++++++ 4 files changed, 601 insertions(+), 5 deletions(-) diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml index 2b2c70a26e..b1ebdae501 100644 --- a/doc/src/sgml/catalogs.sgml +++ b/doc/src/sgml/catalogs.sgml @@ -2183,6 +2183,15 @@ SCRAM-SHA-256$<replaceable><iteration count></replaceable>:<replaceable>&l </para></entry> </row> + <row> + <entry role="catalog_table_entry"><para role="column_definition"> + <structfield>relisivm</structfield> <type>bool</type> + </para> + <para> + True if materialized view enables incremental view maintenance + </para></entry> + </row> + <row> <entry role="catalog_table_entry"><para role="column_definition"> <structfield>relrewrite</structfield> <type>oid</type> @@ -3465,6 +3474,18 @@ SCRAM-SHA-256$<replaceable><iteration count></replaceable>:<replaceable>&l </para> </listitem> </varlistentry> + + <varlistentry> + <term><symbol>DEPENDENCY_IMMV</symbol> (<literal>m</literal>)</term> + <listitem> + <para> + The dependent object was created as part of creation of the Materialized + View with Incremental View Maintenance reference, and is really just a + part of its internal implementation. The dependent object must not be + dropped unless the materialized view is also dropped. + </para> + </listitem> + </varlistentry> </variablelist> Other dependency flavors might be needed in future. @@ -3848,7 +3869,8 @@ SCRAM-SHA-256$<replaceable><iteration count></replaceable>:<replaceable>&l <structfield>extrelocatable</structfield> <type>bool</type> </para> <para> - True if extension can be relocated to another schema + True for materialized views which are enabled for incremental + view maintenance (IVM). </para></entry> </row> diff --git a/doc/src/sgml/ref/create_materialized_view.sgml b/doc/src/sgml/ref/create_materialized_view.sgml index d8c48252f4..5abccf14ba 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 <refsynopsisdiv> <synopsis> -CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> +CREATE [ INCREMENTAL ] MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> [ (<replaceable>column_name</replaceable> [, ...] ) ] [ USING <replaceable class="parameter">method</replaceable> ] [ WITH ( <replaceable class="parameter">storage_parameter</replaceable> [= <replaceable class="parameter">value</replaceable>] [, ... ] ) ] @@ -60,6 +60,134 @@ CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> <title>Parameters</title> <variablelist> + <varlistentry> + <term><literal>INCREMENTAL</literal></term> + <listitem> + <para> + 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). + </para> + <para> + When <acronym>IMMV</acronym> 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. + </para> + <para> + There are restrictions of query definitions allowed to use this + option. The following are supported in query definitions for IMMV: + <itemizedlist> + + <listitem> + <para> + Inner joins (including self-joins). + </para> + </listitem> + + <listitem> + <para> + Some built-in aggregate functions (count, sum, avg, min, max) without a HAVING + clause. + </para> + </listitem> + </itemizedlist> + + Unsupported queries with this option include the following: + + <itemizedlist> + <listitem> + <para> + Outer joins. + </para> + </listitem> + <listitem> + + <listitem> + <para> + Sub-queries. + </para> + </listitem> + <listitem> + + <listitem> + <para> + Aggregate functions other than built-in count, sum, avg, min and max. + </para> + </listitem> + <listitem> + <para> + Aggregate functions with a HAVING clause. + </para> + </listitem> + <listitem> + <para> + DISTINCT ON, WINDOW, VALUES, LIMIT and OFFSET clause. + </para> + </listitem> + </itemizedlist> + + Other restrictions include: + <itemizedlist> + + <listitem> + <para> + IMMVs must be based on simple base tables. It's not supported to + create them on top of views or materialized views. + </para> + </listitem> + + <listitem> + <para> + When the TRUNCATE command is executed on a base table, + no changes are made to the materialized view. + </para> + </listitem> + + <listitem> + <para> + It is not supported to include system columns in an IMMV. + <programlisting> +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 + </programlisting> + </para> + </listitem> + + <listitem> + <para> + Non-immutable functions are not supported. + <programlisting> +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 + </programlisting> + </para> + </listitem> + + <listitem> + <para> + IMMVs do not support expressions that contains aggregates + </para> + </listitem> + + <listitem> + <para> + Logical replication does not support IMMVs. + </para> + </listitem> + + </itemizedlist> + + </para> + </listitem> + </varlistentry> + <varlistentry> <term><literal>IF NOT EXISTS</literal></term> <listitem> @@ -153,7 +281,8 @@ CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> 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 <command>REFRESH - MATERIALIZED VIEW</command> is used. + MATERIALIZED VIEW</command> is used. Also, if the view is IMMV, + triggers for maintaining the view are not created. </para> </listitem> </varlistentry> diff --git a/doc/src/sgml/ref/refresh_materialized_view.sgml b/doc/src/sgml/ref/refresh_materialized_view.sgml index 3bf8884447..dc81853057 100644 --- a/doc/src/sgml/ref/refresh_materialized_view.sgml +++ b/doc/src/sgml/ref/refresh_materialized_view.sgml @@ -35,9 +35,11 @@ REFRESH MATERIALIZED VIEW [ CONCURRENTLY ] <replaceable class="parameter">name</ owner of the materialized view. The old contents are discarded. If <literal>WITH DATA</literal> 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 <literal>WITH NO DATA</literal> is specified no new + scannable state. Also, if the view is an incrementally maintainable materialized + view (IMMV) and was unpopulated, triggers for maintaining + the view are created. If <literal>WITH NO DATA</literal> 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. </para> <para> <literal>CONCURRENTLY</literal> and <literal>WITH NO DATA</literal> may not diff --git a/doc/src/sgml/rules.sgml b/doc/src/sgml/rules.sgml index 5024e4ff70..597332fe96 100644 --- a/doc/src/sgml/rules.sgml +++ b/doc/src/sgml/rules.sgml @@ -1093,6 +1093,449 @@ SELECT word FROM words ORDER BY word <-> 'caterpiler' LIMIT 10; </sect1> +<sect1 id="rules-ivm"> +<title>Incremental View Maintenance</title> + +<indexterm zone="rules-ivm"> + <primary>incremental view maintenance</primary> +</indexterm> + +<indexterm zone="rules-ivm"> + <primary>materialized view</primary> + <secondary>incremental view maintenance</secondary> +</indexterm> + +<indexterm zone="rules-ivm"> + <primary>view</primary> + <secondary>incremental view maintenance</secondary> +</indexterm> + +<sect2 id="rules-ivm-overview"> +<title>Overview</title> + +<para> + Incremental View Maintenance (<acronym>IVM</acronym>) 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 + <command>REFRESH MATERIALIZED VIEW</command> does. <acronym>IVM</acronym> + can update materialized views more efficiently than recomputation when only + small parts of the view are changed. +</para> + +<para> + 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 <command>REFRESH + MATERIALIZED VIEW</command>, or periodically in background, and so on. + <productname>PostgreSQL</productname> currently implements only a kind of + immediate maintenance, in which materialized views are updated immediately + in AFTER triggers when a base table is modified. +</para> + +<para> + To create materialized views supporting <acronym>IVM</acronym>, use the + <command>CREATE INCREMENTAL MATERIALIZED VIEW</command>, for example: +<programlisting> +CREATE <emphasis>INCREMENTAL</emphasis> MATERIALIZED VIEW mymatview AS SELECT * FROM mytab; +</programlisting> + When a materialized view is created with the <literal>INCREMENTAL</literal> + 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 + (<acronym>IMMV</acronym>). +<programlisting> +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) +</programlisting> +</para> + +<para> + Some <acronym>IMMV</acronym>s have hidden columns which are added + automatically when a materialized view is created. Their name starts + with <literal>__ivm_</literal> and they contain information required + for maintaining the <acronym>IMMV</acronym>. Such columns are not visible + when the <acronym>IMMV</acronym> is accessed by <literal>SELECT *</literal> + but are visible if the column name is explicitly specified in the target + list. We can also see the hidden columns in <literal>\d</literal> + meta-commands of <command>psql</command> commands. +</para> + +<para> + In general, <acronym>IMMV</acronym>s allow faster updates of materialized + views at the price of slower updates to their base tables. Updates of + <acronym>IMMV</acronym> is slower because triggers will be invoked and the + view is updated in triggers per modification statement. +</para> + +<para> + For example, suppose a normal materialized view defined as below: + +<programlisting> +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 + +</programlisting> + + Updating a tuple in a base table of this materialized view is rapid but the + <command>REFRESH MATERIALIZED VIEW</command> command on this view takes a long time: + +<programlisting> +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) +</programlisting> +</para> + +<para> + On the other hand, after creating <acronym>IMMV</acronym> with the same view + definition as below: + +<programlisting> +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" +</programlisting> + + 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 + <command>REFRESH MATERIALIZED VIEW</command> command. + +<programlisting> +test=# UPDATE pgbench_accounts SET abalance = 1000 WHERE aid = 1; +UPDATE 1 +Time: 13.068 ms +</programlisting> + +</para> + +<para> + Appropriate indexes on <acronym>IMMV</acronym>s are necessary for + efficient <acronym>IVM</acronym> because it looks for tuples to be + updated in <acronym>IMMV</acronym>. If there are no indexes, it + will take a long time. +</para> + +<para> + Therefore, when <acronym>IMMV</acronym> 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. +</para> + +<para> + 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. +<programlisting> +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) +</programlisting> + +</para> + +<para> + <acronym>IVM</acronym> 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, <acronym>IVM</acronym> + 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, <acronym>IVM</acronym> is not effective and the cost of + maintenance can be larger than the <command>REFRESH MATERIALIZED VIEW</command> + command. In such situation, we can use <command>REFRESH MATERIALIZED VIEW</command> + and specify <literal>WITH NO DATA</literal> to disable immediate + maintenance before modifying a base table. After a base table modification, + execute the <command>REFRESH MATERIALIZED VIEW</command> (with <literal>WITH DATA</literal>) + command to refresh the view data and enable immediate maintenance. +</para> + +</sect2> + +<sect2> +<title>Supported View Definitions and Restrictions</title> + +<para> + Currently, we can create <acronym>IMMV</acronym>s using inner joins, and some + aggregates. However, several restrictions apply to the definition of IMMV. +</para> + +<sect3> +<title>Joins</title> +<para> + Inner joins including self-join are supported. Outer joins are not supported. +</para> +</sect3> + +<sect3> +<title>Aggregates</title> +<para> + Supported aggregate functions are <function>count</function>, <function>sum</function>, + <function>avg</function>, <function>min</function>, and <function>max</function>. + 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 <acronym>IMMV</acronym>. +</para> + +<para> + Note that for <function>min</function> or <function>max</function>, 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 <acronym>IMMV</acronym> containing + these functions. +</para> + +<para> + Also note that using <function>sum</function> or <function>avg</function> on + <type>real</type> (<type>float4</type>) type or <type>double precision</type> + (<type>float8</type>) type in <acronym>IMMV</acronym> is unsafe. This is + because aggregated values in <acronym>IMMV</acronym> can become different from + results calculated from base tables due to the limited precision of these types. + To avoid this problem, use the <type>numeric</type> type instead. +</para> + + <sect4> + <title>Restrictions on Aggregates</title> + <para> + There are the following restrictions: + <itemizedlist> + <listitem> + <para> + If we have a <literal>GROUP BY</literal> clause, expressions specified in + <literal>GROUP BY</literal> must appear in the target list. This is + how tuples to be updated in the <acronym>IMMV</acronym> are identified. + These attributes are used as scan keys for searching tuples in the + <acronym>IMMV</acronym>, so indexes on them are required for efficient + <acronym>IVM</acronym>. + </para> + </listitem> + + <listitem> + <para> + <literal>HAVING</literal> clause cannot be used. + </para> + </listitem> + </itemizedlist> + </para> + </sect4> +</sect3> + +<sect3> +<title>Other General Restrictions</title> +<para> + There are other restrictions which generally apply to <acronym>IMMV</acronym>: + <itemizedlist> + <listitem> + <para> + Sub-queries cannot be used. + </para> + </listitem> + + <listitem> + <para> + CTEs cannot be used. + </para> + </listitem> + + <listitem> + <para> + Window functions cannot be used. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s must be based on simple base tables. It's not + supported to create them on top of views or materialized views. + </para> + </listitem> + + <listitem> + <para> + LIMIT and OFFSET clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s cannot contain system columns. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s cannot contain non-immutable functions. + </para> + </listitem> + + <listitem> + <para> + UNION/INTERSECT/EXCEPT clauses cannnot be used. + </para> + </listitem> + + <listitem> + <para> + DISTINCT ON clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + TABLESAMPLE parameter cannot be used. + </para> + </listitem> + + <listitem> + <para> + inheritance parent tables cannnot be used. + </para> + </listitem> + + <listitem> + <para> + VALUES clause cannnot be used. + </para> + </listitem> + + <listitem> + <para> + <literal>GROUPING SETS</literal> and <literal>FILTER</literal> clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + FOR UPDATE/SHARE cannot be used. + </para> + </listitem> + + <listitem> + <para> + targetlist cannot contain columns whose name start with <literal>__ivm_</literal>. + </para> + </listitem> + + <listitem> + <para> + targetlist cannot contain expressions which contain an aggregate in it. + </para> + </listitem> + + <listitem> + <para> + Logical replication is not supported, that is, even when a base table + at a publisher node is modified, <acronym>IMMV</acronym>s at subscriber + nodes are not updated. + </para> + </listitem> + + <listitem> + <para> + When the <literal>TRUNCATE</literal> command is executed on a base table, + nothing is changed on the <acronym>IMMV</acronym>. + </para> + </listitem> + + </itemizedlist> +</para> +</sect3> + +</sect2> + +<sect2> +<title><literal>DISTINCT</literal></title> + +<para> + <productname>PostgreSQL</productname> supports <acronym>IMMV</acronym> with + <literal>DISTINCT</literal>. For example, suppose a <acronym>IMMV</acronym> + defined with <literal>DISTINCT</literal> 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. +</para> + +<para> + Physically, an <acronym>IMMV</acronym> defined with <literal>DISTINCT</literal> + contains tuples after eliminating duplicates, and the multiplicity of each tuple + is stored in a hidden column named <literal>__ivm_count__</literal>. +</para> +</sect2> + +<sect2> +<title>Concurrent Transactions</title> +<para> + Suppose an <acronym>IMMV</acronym> is defined on two base tables and each + table was modified in different a concurrent transaction simultaneously. + In the transaction which was committed first, <acronym>IMMV</acronym> 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, <literal>ExclusiveLock</literal> + is held on an <acronym>IMMV</acronym> immediately after a base table is + modified in <literal>READ COMMITTED</literal> mode to make sure that + the <acronym>IMMV</acronym> is updated in the latter transaction after + the former transaction is committed. In <literal>REPEATABLE READ</literal> + or <literal>SERIALIZABLE</literal> 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 + <acronym>IMMV</acronym> cannot be updated correctly in such situations. + However, as an exception if the view has only one base table, + the lock held on thew view is <literal>RowExclusiveLock</literal>. +</para> +</sect2> + +<sect2> +<title>Row Level Security</title> +<para> + 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. +</para> +</sect2> + +</sect1> + <sect1 id="rules-update"> <title>Rules on <command>INSERT</command>, <command>UPDATE</command>, and <command>DELETE</command></title> -- 2.17.1 --Multipart=_Mon__2_Aug_2021_15_28_34_+0900_wlHCjIpnD/FrGAKu-- ^ permalink raw reply [nested|flat] 22+ messages in thread
* [PATCH v37 11/11] Add documentations about Incremental View Maintenance @ 2019-12-20 01:25 Yugo Nagata <[email protected]> 0 siblings, 0 replies; 22+ messages in thread From: Yugo Nagata @ 2019-12-20 01:25 UTC (permalink / raw) --- 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 4b474c13917..9b1c88161a7 100644 --- a/doc/src/sgml/catalogs.sgml +++ b/doc/src/sgml/catalogs.sgml @@ -2276,6 +2276,15 @@ SCRAM-SHA-256$<replaceable><iteration count></replaceable>:<replaceable>&l </para></entry> </row> + <row> + <entry role="catalog_table_entry"><para role="column_definition"> + <structfield>relisivm</structfield> <type>bool</type> + </para> + <para> + True if relation is incrementally maintainable materialized view + </para></entry> + </row> + <row> <entry role="catalog_table_entry"><para role="column_definition"> <structfield>relrewrite</structfield> <type>oid</type> diff --git a/doc/src/sgml/ref/create_materialized_view.sgml b/doc/src/sgml/ref/create_materialized_view.sgml index 62d897931c3..f49db209558 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 <refsynopsisdiv> <synopsis> -CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> +CREATE [ INCREMENTAL ] MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> [ (<replaceable>column_name</replaceable> [, ...] ) ] [ USING <replaceable class="parameter">method</replaceable> ] [ WITH ( <replaceable class="parameter">storage_parameter</replaceable> [= <replaceable class="parameter">value</replaceable>] [, ... ] ) ] @@ -60,6 +60,125 @@ CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> <title>Parameters</title> <variablelist> + <varlistentry> + <term><literal>INCREMENTAL</literal></term> + <listitem> + <para> + 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). + </para> + <para> + When <acronym>IMMV</acronym> is defined without using <command>WITH NO DATA</command>, + 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. + </para> + <para> + There are restrictions of query definitions allowed to use this + option. The following are supported in query definitions for IMMV: + <itemizedlist> + + <listitem> + <para> + Inner joins (including self-joins). + </para> + </listitem> + + <listitem> + <para> + Some built-in aggregate functions (count, sum, avg, min, max) without a HAVING + clause. + </para> + </listitem> + </itemizedlist> + + Unsupported queries with this option include the following: + + <itemizedlist> + <listitem> + <para> + Outer joins. + </para> + </listitem> + + <listitem> + <para> + Sub-queries. + </para> + </listitem> + + <listitem> + <para> + Aggregate functions other than built-in count, sum, avg, min and max. + </para> + </listitem> + <listitem> + <para> + Aggregate functions with a HAVING clause. + </para> + </listitem> + <listitem> + <para> + DISTINCT ON, WINDOW, VALUES, LIMIT and OFFSET clause. + </para> + </listitem> + </itemizedlist> + + Other restrictions include: + <itemizedlist> + + <listitem> + <para> + IMMVs must be based on simple base tables. It's not supported to + create them on top of views or materialized views. + </para> + </listitem> + + <listitem> + <para> + It is not supported to include system columns in an IMMV. + <programlisting> +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 + </programlisting> + </para> + </listitem> + + <listitem> + <para> + Non-immutable functions are not supported. + <programlisting> +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 + </programlisting> + </para> + </listitem> + + <listitem> + <para> + IMMVs do not support expressions that contains aggregates + </para> + </listitem> + + <listitem> + <para> + Logical replication does not support IMMVs. + </para> + </listitem> + + </itemizedlist> + + </para> + </listitem> + </varlistentry> + <varlistentry> <term><literal>IF NOT EXISTS</literal></term> <listitem> @@ -157,7 +276,8 @@ CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] <replaceable>table_name</replaceable> 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 <command>REFRESH - MATERIALIZED VIEW</command> is used. + MATERIALIZED VIEW</command> is used. Also, if the view is IMMV, + triggers for maintaining the view are not created. </para> </listitem> </varlistentry> diff --git a/doc/src/sgml/ref/refresh_materialized_view.sgml b/doc/src/sgml/ref/refresh_materialized_view.sgml index 8ed43ade803..a4d729bdf0f 100644 --- a/doc/src/sgml/ref/refresh_materialized_view.sgml +++ b/doc/src/sgml/ref/refresh_materialized_view.sgml @@ -36,9 +36,13 @@ REFRESH MATERIALIZED VIEW [ CONCURRENTLY ] <replaceable class="parameter">name</ privilege on the materialized view. The old contents are discarded. If <literal>WITH DATA</literal> 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 <literal>WITH NO DATA</literal> 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 <literal>WITH NO DATA</literal> 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. </para> <para> <literal>CONCURRENTLY</literal> and <literal>WITH NO DATA</literal> may not diff --git a/doc/src/sgml/rules.sgml b/doc/src/sgml/rules.sgml index 7f23962f524..da9ad3c6316 100644 --- a/doc/src/sgml/rules.sgml +++ b/doc/src/sgml/rules.sgml @@ -1103,6 +1103,443 @@ SELECT word FROM words ORDER BY word <-> 'caterpiler' LIMIT 10; </sect1> +<sect1 id="rules-ivm"> +<title>Incremental View Maintenance</title> + +<indexterm zone="rules-ivm"> + <primary>incremental view maintenance</primary> +</indexterm> + +<indexterm zone="rules-ivm"> + <primary>materialized view</primary> + <secondary>incremental view maintenance</secondary> +</indexterm> + +<indexterm zone="rules-ivm"> + <primary>view</primary> + <secondary>incremental view maintenance</secondary> +</indexterm> + +<sect2 id="rules-ivm-overview"> +<title>Overview</title> + +<para> + Incremental View Maintenance (<acronym>IVM</acronym>) 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 + <command>REFRESH MATERIALIZED VIEW</command> does. <acronym>IVM</acronym> + can update materialized views more efficiently than recomputation when only + small parts of the view are changed. +</para> + +<para> + 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 <command>REFRESH + MATERIALIZED VIEW</command>, or periodically in background, and so on. + <productname>PostgreSQL</productname> currently implements only a kind of + immediate maintenance, in which materialized views are updated immediately + in AFTER triggers when a base table is modified. +</para> + +<para> + To create materialized views supporting <acronym>IVM</acronym>, use the + <command>CREATE INCREMENTAL MATERIALIZED VIEW</command>, for example: +<programlisting> +CREATE <emphasis>INCREMENTAL</emphasis> MATERIALIZED VIEW mymatview AS SELECT * FROM mytab; +</programlisting> + When a materialized view is created with the <literal>INCREMENTAL</literal> + 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 + (<acronym>IMMV</acronym>). +<programlisting> +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) +</programlisting> +</para> + +<para> + Some <acronym>IMMV</acronym>s have hidden columns which are added + automatically when a materialized view is created. Their name starts + with <literal>__ivm_</literal> and they contain information required + for maintaining the <acronym>IMMV</acronym>. Such columns are not visible + when the <acronym>IMMV</acronym> is accessed by <literal>SELECT *</literal> + but are visible if the column name is explicitly specified in the target + list. We can also see the hidden columns in <literal>\d</literal> + meta-commands of <command>psql</command> commands. +</para> + +<para> + In general, <acronym>IMMV</acronym>s allow faster updates of materialized + views at the price of slower updates to their base tables. Updates of + <acronym>IMMV</acronym> is slower because triggers will be invoked and the + view is updated in triggers per modification statement. +</para> + +<para> + For example, suppose a normal materialized view defined as below: + +<programlisting> +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 + +</programlisting> + + Updating a tuple in a base table of this materialized view is rapid but the + <command>REFRESH MATERIALIZED VIEW</command> command on this view takes a long time: + +<programlisting> +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) +</programlisting> +</para> + +<para> + On the other hand, after creating <acronym>IMMV</acronym> with the same view + definition as below: + +<programlisting> +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" +</programlisting> + + 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 + <command>REFRESH MATERIALIZED VIEW</command> command. + +<programlisting> +test=# UPDATE pgbench_accounts SET abalance = 1000 WHERE aid = 1; +UPDATE 1 +Time: 13.068 ms +</programlisting> + +</para> + +<para> + Appropriate indexes on <acronym>IMMV</acronym>s are necessary for + efficient <acronym>IVM</acronym> because it looks for tuples to be + updated in <acronym>IMMV</acronym>. If there are no indexes, it + will take a long time. +</para> + +<para> + Therefore, when <acronym>IMMV</acronym> 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. +</para> + +<para> + 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. +<programlisting> +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) +</programlisting> + +</para> + +<para> + <acronym>IVM</acronym> 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, <acronym>IVM</acronym> + 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, <acronym>IVM</acronym> is not effective and the cost of + maintenance can be larger than the <command>REFRESH MATERIALIZED VIEW</command> + command. In such situation, we can use <command>REFRESH MATERIALIZED VIEW</command> + and specify <literal>WITH NO DATA</literal> to disable immediate + maintenance before modifying a base table. After a base table modification, + execute the <command>REFRESH MATERIALIZED VIEW</command> (with <literal>WITH DATA</literal>) + command to refresh the view data and enable immediate maintenance. +</para> + +</sect2> + +<sect2 id="rules-ivm-support"> +<title>Supported View Definitions and Restrictions</title> + +<para> + Currently, we can create <acronym>IMMV</acronym>s using inner joins, and some + aggregates. However, several restrictions apply to the definition of IMMV. +</para> + +<sect3 id="rules-ivm-support-joins"> +<title>Joins</title> +<para> + Inner joins including self-join are supported. Outer joins are not supported. +</para> +</sect3> + +<sect3 id="rules-ivm-support-aggregates"> +<title>Aggregates</title> +<para> + Supported aggregate functions are <function>count</function>, <function>sum</function>, + <function>avg</function>, <function>min</function>, and <function>max</function>. + 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 <acronym>IMMV</acronym>. +</para> + +<para> + Note that for <function>min</function> or <function>max</function>, 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 <acronym>IMMV</acronym> containing + these functions. +</para> + +<para> + Also note that using <function>sum</function> or <function>avg</function> on + <type>real</type> (<type>float4</type>) type or <type>double precision</type> + (<type>float8</type>) type in <acronym>IMMV</acronym> is unsafe. This is + because aggregated values in <acronym>IMMV</acronym> can become different from + results calculated from base tables due to the limited precision of these types. + To avoid this problem, use the <type>numeric</type> type instead. +</para> + + <sect4 id="rules-ivm-restrictions-aggregates"> + <title>Restrictions on Aggregates</title> + <para> + There are the following restrictions: + <itemizedlist> + <listitem> + <para> + If we have a <literal>GROUP BY</literal> clause, expressions specified in + <literal>GROUP BY</literal> must appear in the target list. This is + how tuples to be updated in the <acronym>IMMV</acronym> are identified. + These attributes are used as scan keys for searching tuples in the + <acronym>IMMV</acronym>, so indexes on them are required for efficient + <acronym>IVM</acronym>. + </para> + </listitem> + + <listitem> + <para> + <literal>HAVING</literal> clause cannot be used. + </para> + </listitem> + </itemizedlist> + </para> + </sect4> +</sect3> + +<sect3 id="rules-ivm-general-restricitons"> +<title>Other General Restrictions</title> +<para> + There are other restrictions which generally apply to <acronym>IMMV</acronym>: + <itemizedlist> + <listitem> + <para> + Sub-queries cannot be used. + </para> + </listitem> + + <listitem> + <para> + CTEs cannot be used. + </para> + </listitem> + + <listitem> + <para> + Window functions cannot be used. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s must be based on simple base tables. It's not + supported to create them on top of views, materialized views, foreign tables, inhe. + </para> + </listitem> + + <listitem> + <para> + LIMIT and OFFSET clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s cannot contain system columns. + </para> + </listitem> + + <listitem> + <para> + <acronym>IMMV</acronym>s cannot contain non-immutable functions. + </para> + </listitem> + + <listitem> + <para> + UNION/INTERSECT/EXCEPT clauses cannnot be used. + </para> + </listitem> + + <listitem> + <para> + DISTINCT ON clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + TABLESAMPLE parameter cannot be used. + </para> + </listitem> + + <listitem> + <para> + inheritance parent tables cannnot be used. + </para> + </listitem> + + <listitem> + <para> + VALUES clause cannnot be used. + </para> + </listitem> + + <listitem> + <para> + <literal>GROUPING SETS</literal> and <literal>FILTER</literal> clauses cannot be used. + </para> + </listitem> + + <listitem> + <para> + FOR UPDATE/SHARE cannot be used. + </para> + </listitem> + + <listitem> + <para> + targetlist cannot contain columns whose name start with <literal>__ivm_</literal>. + </para> + </listitem> + + <listitem> + <para> + targetlist cannot contain expressions which contain an aggregate in it. + </para> + </listitem> + + <listitem> + <para> + Logical replication is not supported, that is, even when a base table + at a publisher node is modified, <acronym>IMMV</acronym>s at subscriber + nodes are not updated. + </para> + </listitem> + + </itemizedlist> +</para> +</sect3> + +</sect2> + +<sect2 id="rules-ivm-distinct"> +<title><literal>DISTINCT</literal></title> + +<para> + <productname>PostgreSQL</productname> supports <acronym>IMMV</acronym> with + <literal>DISTINCT</literal>. For example, suppose a <acronym>IMMV</acronym> + defined with <literal>DISTINCT</literal> 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. +</para> + +<para> + Physically, an <acronym>IMMV</acronym> defined with <literal>DISTINCT</literal> + contains tuples after eliminating duplicates, and the multiplicity of each tuple + is stored in a hidden column named <literal>__ivm_count__</literal>. +</para> +</sect2> + +<sect2 id="rules-ivm-concurrent-transactions"> +<title>Concurrent Transactions</title> +<para> + Suppose an <acronym>IMMV</acronym> is defined on two base tables and each + table was modified in different a concurrent transaction simultaneously. + In the transaction which was committed first, <acronym>IMMV</acronym> 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, <literal>ExclusiveLock</literal> + is held on an <acronym>IMMV</acronym> immediately after a base table is + modified in <literal>READ COMMITTED</literal> mode to make sure that + the <acronym>IMMV</acronym> is updated in the latter transaction after + the former transaction is committed. In <literal>REPEATABLE READ</literal> + or <literal>SERIALIZABLE</literal> 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 + <acronym>IMMV</acronym> cannot be updated correctly in such situations. + However, as an exception if the view has only one base table and + <command>INSERT</command> is performed on the table, + the lock held on thew view is <literal>RowExclusiveLock</literal>. +</para> +</sect2> + +<sect2 id="rules-ivm-rls"> +<title>Row Level Security</title> +<para> + 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. +</para> +</sect2> + +</sect1> + <sect1 id="rules-update"> <title>Rules on <command>INSERT</command>, <command>UPDATE</command>, and <command>DELETE</command></title> diff --git a/doc/src/sgml/system-views.sgml b/doc/src/sgml/system-views.sgml index 2ebec6928d5..65d1e2041d2 100644 --- a/doc/src/sgml/system-views.sgml +++ b/doc/src/sgml/system-views.sgml @@ -2231,6 +2231,15 @@ SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx </para></entry> </row> + <row> + <entry role="catalog_table_entry"><para role="column_definition"> + <structfield>isimmv</structfield> <type>bool</type> + </para> + <para> + True if materialized view is incrementally maintainable + </para></entry> + </row> + <row> <entry role="catalog_table_entry"><para role="column_definition"> <structfield>definition</structfield> <type>text</type> -- 2.43.0 --Multipart=_Fri__29_May_2026_23_14_17_+0900_Te0o73X2VqYK57Gd Content-Type: text/x-diff; name="v37-0010-Add-regression-tests-for-Incremental-View-Mainte.patch" Content-Disposition: attachment; filename="v37-0010-Add-regression-tests-for-Incremental-View-Mainte.patch" Content-Transfer-Encoding: 7bit ^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: pgstat include expansion @ 2026-02-26 16:19 Alvaro Herrera <[email protected]> 0 siblings, 0 replies; 22+ messages in thread From: Alvaro Herrera @ 2026-02-26 16:19 UTC (permalink / raw) To: Andres Freund <[email protected]>; +Cc: Heikki Linnakangas <[email protected]>; pgsql-hackers; Amit Kapila <[email protected]>; Michael Paquier <[email protected]> On 2026-Feb-26, Alvaro Herrera wrote: > However, maybe we can just not be so principled about it, add it to > latch.h, and then we don't break the whole world. I'll try that. This one does it that way. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "Cuando mañana llegue pelearemos segun lo que mañana exija" (Mowgli) Attachments: [text/x-diff] v3-0001-Don-t-include-wait_event.h-in-pgstat.h.patch (7.8K, ../../[email protected]/2-v3-0001-Don-t-include-wait_event.h-in-pgstat.h.patch) download | inline diff: From 716ff1063aa274c1bfcff83515da8d706c03e657 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=C3=81lvaro=20Herrera?= <[email protected]> Date: Thu, 26 Feb 2026 17:15:22 +0100 Subject: [PATCH v3] Don't include wait_event.h in pgstat.h Avoid breaking too much third-party code by including wait_events.h in latch.h; this makes sense anyway, because many extension do WaitLatch() using a wait event value. Discussion: https://postgr.es/m/[email protected] --- src/backend/access/transam/slru.c | 1 + src/backend/access/transam/timeline.c | 1 + src/backend/access/transam/xlogarchive.c | 1 + src/backend/access/transam/xlogreader.c | 1 + src/backend/archive/shell_archive.c | 1 + src/backend/backup/basebackup.c | 1 + src/backend/replication/logical/origin.c | 1 + src/backend/storage/file/buffile.c | 1 + src/backend/storage/file/copydir.c | 1 + src/backend/storage/file/fd.c | 1 + src/backend/storage/ipc/dsm_impl.c | 1 + src/backend/storage/smgr/md.c | 1 + src/backend/utils/cache/relmapper.c | 1 + src/common/controldata_utils.c | 1 + src/include/pgstat.h | 1 - src/include/storage/latch.h | 1 + 16 files changed, 15 insertions(+), 1 deletion(-) diff --git a/src/backend/access/transam/slru.c b/src/backend/access/transam/slru.c index 549c7e3e64b..556edcbf7cb 100644 --- a/src/backend/access/transam/slru.c +++ b/src/backend/access/transam/slru.c @@ -71,6 +71,7 @@ #include "storage/fd.h" #include "storage/shmem.h" #include "utils/guc.h" +#include "utils/wait_event.h" /* * Converts segment number to the filename of the segment. diff --git a/src/backend/access/transam/timeline.c b/src/backend/access/transam/timeline.c index 60ee28665b1..68e5f692d26 100644 --- a/src/backend/access/transam/timeline.c +++ b/src/backend/access/transam/timeline.c @@ -41,6 +41,7 @@ #include "access/xlogdefs.h" #include "pgstat.h" #include "storage/fd.h" +#include "utils/wait_event.h" /* * Copies all timeline history files with id's between 'begin' and 'end' diff --git a/src/backend/access/transam/xlogarchive.c b/src/backend/access/transam/xlogarchive.c index aa0c2fe3afd..9a0c8097cb1 100644 --- a/src/backend/access/transam/xlogarchive.c +++ b/src/backend/access/transam/xlogarchive.c @@ -31,6 +31,7 @@ #include "replication/walsender.h" #include "storage/fd.h" #include "storage/ipc.h" +#include "utils/wait_event.h" /* * Attempt to retrieve the specified file from off-line archival storage. diff --git a/src/backend/access/transam/xlogreader.c b/src/backend/access/transam/xlogreader.c index 03ada8aa0c5..8cb2110cb99 100644 --- a/src/backend/access/transam/xlogreader.c +++ b/src/backend/access/transam/xlogreader.c @@ -36,6 +36,7 @@ #ifndef FRONTEND #include "pgstat.h" #include "storage/bufmgr.h" +#include "utils/wait_event.h" #else #include "common/logging.h" #endif diff --git a/src/backend/archive/shell_archive.c b/src/backend/archive/shell_archive.c index 5b565968818..0b427a68809 100644 --- a/src/backend/archive/shell_archive.c +++ b/src/backend/archive/shell_archive.c @@ -22,6 +22,7 @@ #include "archive/shell_archive.h" #include "common/percentrepl.h" #include "pgstat.h" +#include "utils/wait_event.h" static bool shell_archive_configured(ArchiveModuleState *state); static bool shell_archive_file(ArchiveModuleState *state, diff --git a/src/backend/backup/basebackup.c b/src/backend/backup/basebackup.c index 2d74c648335..ab1fbae8001 100644 --- a/src/backend/backup/basebackup.c +++ b/src/backend/backup/basebackup.c @@ -48,6 +48,7 @@ #include "utils/ps_status.h" #include "utils/relcache.h" #include "utils/resowner.h" +#include "utils/wait_event.h" /* * How much data do we want to send in one CopyData message? Note that diff --git a/src/backend/replication/logical/origin.c b/src/backend/replication/logical/origin.c index c3271a6fd0e..26afd8f0af9 100644 --- a/src/backend/replication/logical/origin.c +++ b/src/backend/replication/logical/origin.c @@ -95,6 +95,7 @@ #include "utils/rel.h" #include "utils/snapmgr.h" #include "utils/syscache.h" +#include "utils/wait_event.h" /* paths for replication origin checkpoint files */ #define PG_REPLORIGIN_CHECKPOINT_FILENAME PG_LOGICAL_DIR "/replorigin_checkpoint" diff --git a/src/backend/storage/file/buffile.c b/src/backend/storage/file/buffile.c index ddf3a410d6f..c4afe4d368a 100644 --- a/src/backend/storage/file/buffile.c +++ b/src/backend/storage/file/buffile.c @@ -53,6 +53,7 @@ #include "storage/bufmgr.h" #include "storage/fd.h" #include "utils/resowner.h" +#include "utils/wait_event.h" /* * We break BufFiles into gigabyte-sized segments, regardless of RELSEG_SIZE. diff --git a/src/backend/storage/file/copydir.c b/src/backend/storage/file/copydir.c index 596d9070fd8..5ee141f13a5 100644 --- a/src/backend/storage/file/copydir.c +++ b/src/backend/storage/file/copydir.c @@ -29,6 +29,7 @@ #include "pgstat.h" #include "storage/copydir.h" #include "storage/fd.h" +#include "utils/wait_event.h" /* GUCs */ int file_copy_method = FILE_COPY_METHOD_COPY; diff --git a/src/backend/storage/file/fd.c b/src/backend/storage/file/fd.c index 5d07b64a1ef..01f1bd6e687 100644 --- a/src/backend/storage/file/fd.c +++ b/src/backend/storage/file/fd.c @@ -101,6 +101,7 @@ #include "utils/guc_hooks.h" #include "utils/resowner.h" #include "utils/varlena.h" +#include "utils/wait_event.h" /* Define PG_FLUSH_DATA_WORKS if we have an implementation for pg_flush_data */ #if defined(HAVE_SYNC_FILE_RANGE) diff --git a/src/backend/storage/ipc/dsm_impl.c b/src/backend/storage/ipc/dsm_impl.c index e208457df27..e8c07805f59 100644 --- a/src/backend/storage/ipc/dsm_impl.c +++ b/src/backend/storage/ipc/dsm_impl.c @@ -68,6 +68,7 @@ #include "storage/fd.h" #include "utils/guc.h" #include "utils/memutils.h" +#include "utils/wait_event.h" #ifdef USE_DSM_POSIX static bool dsm_impl_posix(dsm_op op, dsm_handle handle, Size request_size, diff --git a/src/backend/storage/smgr/md.c b/src/backend/storage/smgr/md.c index 443434e4ea8..dee29037b16 100644 --- a/src/backend/storage/smgr/md.c +++ b/src/backend/storage/smgr/md.c @@ -40,6 +40,7 @@ #include "storage/smgr.h" #include "storage/sync.h" #include "utils/memutils.h" +#include "utils/wait_event.h" /* * The magnetic disk storage manager keeps track of open file diff --git a/src/backend/utils/cache/relmapper.c b/src/backend/utils/cache/relmapper.c index 778b14a2318..3aaf466868d 100644 --- a/src/backend/utils/cache/relmapper.c +++ b/src/backend/utils/cache/relmapper.c @@ -54,6 +54,7 @@ #include "storage/lwlock.h" #include "utils/inval.h" #include "utils/relmapper.h" +#include "utils/wait_event.h" /* diff --git a/src/common/controldata_utils.c b/src/common/controldata_utils.c index 14530c6489a..4ab116afcde 100644 --- a/src/common/controldata_utils.c +++ b/src/common/controldata_utils.c @@ -37,6 +37,7 @@ #ifndef FRONTEND #include "pgstat.h" #include "storage/fd.h" +#include "utils/wait_event.h" #endif /* diff --git a/src/include/pgstat.h b/src/include/pgstat.h index 0e9d2b4c623..216b93492ba 100644 --- a/src/include/pgstat.h +++ b/src/include/pgstat.h @@ -18,7 +18,6 @@ #include "utils/backend_progress.h" /* for backward compatibility */ /* IWYU pragma: export */ #include "utils/backend_status.h" /* for backward compatibility */ /* IWYU pragma: export */ #include "utils/pgstat_kind.h" -#include "utils/wait_event.h" /* for backward compatibility */ /* IWYU pragma: export */ /* avoid including access/transam.h */ diff --git a/src/include/storage/latch.h b/src/include/storage/latch.h index fbdadc86959..cbefc7ed154 100644 --- a/src/include/storage/latch.h +++ b/src/include/storage/latch.h @@ -104,6 +104,7 @@ #include <signal.h> #include "storage/waiteventset.h" /* for WL_* arguments to WaitLatch */ +#include "utils/wait_event.h" /* IWYU pragma: export */ /* * Latch structure should be treated as opaque and only accessed through -- 2.47.3 ^ permalink raw reply [nested|flat] 22+ messages in thread
end of thread, other threads:[~2026-02-26 16:19 UTC | newest] Thread overview: 22+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2019-12-20 01:25 [PATCH v31 11/11] Add documentations about Incremental View Maintenance Yugo Nagata <[email protected]> 2019-12-20 01:25 [PATCH v27 9/9] Add documentations about Incremental View Maintenance Yugo Nagata <[email protected]> 2019-12-20 01:25 [PATCH v37 11/11] Add documentations about Incremental View Maintenance Yugo Nagata <[email protected]> 2019-12-20 01:25 [PATCH v27 9/9] Add documentations about Incremental View Maintenance Yugo Nagata <[email protected]> 2019-12-20 01:25 [PATCH v26 10/10] Add documentations about Incremental View Maintenance Yugo Nagata <[email protected]> 2019-12-20 01:25 [PATCH v24 10/15] Add documentations about Incremental View Maintenance Yugo Nagata <[email protected]> 2019-12-20 01:25 [PATCH v37 11/11] Add documentations about Incremental View Maintenance Yugo Nagata <[email protected]> 2019-12-20 01:25 [PATCH v30 11/11] Add documentations about Incremental View Maintenance Yugo Nagata <[email protected]> 2019-12-20 01:25 [PATCH v30 11/11] Add documentations about Incremental View Maintenance Yugo Nagata <[email protected]> 2019-12-20 01:25 [PATCH v24 10/15] Add documentations about Incremental View Maintenance Yugo Nagata <[email protected]> 2019-12-20 01:25 [PATCH v29 11/11] Add documentations about Incremental View Maintenance Yugo Nagata <[email protected]> 2019-12-20 01:25 [PATCH v29 11/11] Add documentations about Incremental View Maintenance Yugo Nagata <[email protected]> 2019-12-20 01:25 [PATCH v30 11/11] Add documentations about Incremental View Maintenance Yugo Nagata <[email protected]> 2019-12-20 01:25 [PATCH v23 10/15] Add documentations about Incremental View Maintenance Yugo Nagata <[email protected]> 2019-12-20 01:25 [PATCH v38 11/11] Add documentations about Incremental View Maintenance Yugo Nagata <[email protected]> 2019-12-20 01:25 [PATCH v28 11/11] Add documentations about Incremental View Maintenance Yugo Nagata <[email protected]> 2019-12-20 01:25 [PATCH v32 11/11] Add documentations about Incremental View Maintenance Yugo Nagata <[email protected]> 2019-12-20 01:25 [PATCH v25 10/15] Add documentations about Incremental View Maintenance Yugo Nagata <[email protected]> 2019-12-20 01:25 [PATCH v37 11/11] Add documentations about Incremental View Maintenance Yugo Nagata <[email protected]> 2019-12-20 01:25 [PATCH v38 11/11] Add documentations about Incremental View Maintenance Yugo Nagata <[email protected]> 2019-12-20 01:25 [PATCH v38 11/11] Add documentations about Incremental View Maintenance Yugo Nagata <[email protected]> 2026-02-26 16:19 Re: pgstat include expansion Alvaro Herrera <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox