2013-03-04 01:23:31 +01:00
|
|
|
<!--
|
|
|
|
doc/src/sgml/ref/refresh_materialized_view.sgml
|
|
|
|
PostgreSQL documentation
|
|
|
|
-->
|
|
|
|
|
2017-10-20 03:16:39 +02:00
|
|
|
<refentry id="sql-refreshmaterializedview">
|
2014-02-24 03:25:35 +01:00
|
|
|
<indexterm zone="sql-refreshmaterializedview">
|
|
|
|
<primary>REFRESH MATERIALIZED VIEW</primary>
|
|
|
|
</indexterm>
|
|
|
|
|
2013-03-04 01:23:31 +01:00
|
|
|
<refmeta>
|
|
|
|
<refentrytitle>REFRESH MATERIALIZED VIEW</refentrytitle>
|
|
|
|
<manvolnum>7</manvolnum>
|
|
|
|
<refmiscinfo>SQL - Language Statements</refmiscinfo>
|
|
|
|
</refmeta>
|
|
|
|
|
|
|
|
<refnamediv>
|
|
|
|
<refname>REFRESH MATERIALIZED VIEW</refname>
|
|
|
|
<refpurpose>replace the contents of a materialized view</refpurpose>
|
|
|
|
</refnamediv>
|
|
|
|
|
|
|
|
<refsynopsisdiv>
|
|
|
|
<synopsis>
|
2017-10-09 04:00:57 +02:00
|
|
|
REFRESH MATERIALIZED VIEW [ CONCURRENTLY ] <replaceable class="parameter">name</replaceable>
|
2013-03-04 01:23:31 +01:00
|
|
|
[ WITH [ NO ] DATA ]
|
|
|
|
</synopsis>
|
|
|
|
</refsynopsisdiv>
|
|
|
|
|
|
|
|
<refsect1>
|
|
|
|
<title>Description</title>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
<command>REFRESH MATERIALIZED VIEW</command> completely replaces the
|
2018-08-17 04:29:15 +02:00
|
|
|
contents of a materialized view. To execute this command you must be the
|
|
|
|
owner of the materialized view. The old contents are discarded. If
|
2013-03-04 01:23:31 +01:00
|
|
|
<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
|
|
|
|
data is generated and the materialized view is left in an unscannable
|
|
|
|
state.
|
|
|
|
</para>
|
2013-07-16 19:55:44 +02:00
|
|
|
<para>
|
|
|
|
<literal>CONCURRENTLY</literal> and <literal>WITH NO DATA</literal> may not
|
|
|
|
be specified together.
|
|
|
|
</para>
|
2013-03-04 01:23:31 +01:00
|
|
|
</refsect1>
|
|
|
|
|
|
|
|
<refsect1>
|
|
|
|
<title>Parameters</title>
|
|
|
|
|
|
|
|
<variablelist>
|
2013-07-16 19:55:44 +02:00
|
|
|
<varlistentry>
|
|
|
|
<term><literal>CONCURRENTLY</literal></term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
Refresh the materialized view without locking out concurrent selects on
|
|
|
|
the materialized view. Without this option a refresh which affects a
|
|
|
|
lot of rows will tend to use fewer resources and complete more quickly,
|
|
|
|
but could block other connections which are trying to read from the
|
|
|
|
materialized view. This option may be faster in cases where a small
|
|
|
|
number of rows are affected.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
This option is only allowed if there is at least one
|
|
|
|
<literal>UNIQUE</literal> index on the materialized view which uses only
|
2019-10-24 02:29:02 +02:00
|
|
|
column names and includes all rows; that is, it must not be an
|
|
|
|
expression index or include a <literal>WHERE</literal> clause.
|
2013-07-16 19:55:44 +02:00
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
This option may not be used when the materialized view is not already
|
|
|
|
populated.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
Even with this option only one <literal>REFRESH</literal> at a time may
|
|
|
|
run against any one materialized view.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
2013-03-04 01:23:31 +01:00
|
|
|
<varlistentry>
|
2017-10-09 04:00:57 +02:00
|
|
|
<term><replaceable class="parameter">name</replaceable></term>
|
2013-03-04 01:23:31 +01:00
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
The name (optionally schema-qualified) of the materialized view to
|
|
|
|
refresh.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
</variablelist>
|
|
|
|
</refsect1>
|
|
|
|
|
|
|
|
<refsect1>
|
|
|
|
<title>Notes</title>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
While the default index for future
|
Improve <xref> vs. <command> formatting in the documentation
SQL commands are generally marked up as <command>, except when a link
to a reference page is used using <xref>. But the latter doesn't
create monospace markup, so this looks strange especially when a
paragraph contains a mix of links and non-links.
We considered putting <command> in the <refentrytitle> on the target
side, but that creates some formatting side effects elsewhere.
Generally, it seems safer to solve this on the link source side.
We can't put the <xref> inside the <command>; the DTD doesn't allow
this. DocBook 5 would allow the <command> to have the linkend
attribute itself, but we are not there yet.
So to solve this for now, convert the <xref>s to <link> plus
<command>. This gives the correct look and also gives some more
flexibility what we can put into the link text (e.g., subcommands or
other clauses). In the future, these could then be converted to
DocBook 5 style.
I haven't converted absolutely all xrefs to SQL command reference
pages, only those where we care about the appearance of the link text
or where it was otherwise appropriate to make the appearance match a
bit better. Also in some cases, the links where repetitive, so in
those cases the links where just removed and replaced by a plain
<command>. In cases where we just want the link and don't
specifically care about the generated link text (typically phrased
"for further information see <xref ...>") the xref is kept.
Reported-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Discussion: https://www.postgresql.org/message-id/flat/87o8pco34z.fsf@wibble.ilmari.org
2020-10-03 16:16:51 +02:00
|
|
|
<link linkend="sql-cluster"><command>CLUSTER</command></link>
|
2017-10-09 03:44:17 +02:00
|
|
|
operations is retained, <command>REFRESH MATERIALIZED VIEW</command> does not
|
2013-03-04 01:23:31 +01:00
|
|
|
order the generated rows based on this property. If you want the data
|
2017-10-09 03:44:17 +02:00
|
|
|
to be ordered upon generation, you must use an <literal>ORDER BY</literal>
|
2013-03-04 01:23:31 +01:00
|
|
|
clause in the backing query.
|
|
|
|
</para>
|
|
|
|
</refsect1>
|
|
|
|
|
|
|
|
<refsect1>
|
|
|
|
<title>Examples</title>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
This command will replace the contents of the materialized view called
|
|
|
|
<literal>order_summary</literal> using the query from the materialized
|
|
|
|
view's definition, and leave it in a scannable state:
|
|
|
|
<programlisting>
|
|
|
|
REFRESH MATERIALIZED VIEW order_summary;
|
|
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
This command will free storage associated with the materialized view
|
|
|
|
<literal>annual_statistics_basis</literal> and leave it in an unscannable
|
|
|
|
state:
|
|
|
|
<programlisting>
|
|
|
|
REFRESH MATERIALIZED VIEW annual_statistics_basis WITH NO DATA;
|
2013-06-02 04:03:02 +02:00
|
|
|
</programlisting></para>
|
2013-03-04 01:23:31 +01:00
|
|
|
</refsect1>
|
|
|
|
|
|
|
|
<refsect1>
|
|
|
|
<title>Compatibility</title>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
<command>REFRESH MATERIALIZED VIEW</command> is a
|
|
|
|
<productname>PostgreSQL</productname> extension.
|
|
|
|
</para>
|
|
|
|
</refsect1>
|
|
|
|
|
|
|
|
<refsect1>
|
|
|
|
<title>See Also</title>
|
|
|
|
|
|
|
|
<simplelist type="inline">
|
2017-11-23 15:39:47 +01:00
|
|
|
<member><xref linkend="sql-creatematerializedview"/></member>
|
|
|
|
<member><xref linkend="sql-altermaterializedview"/></member>
|
|
|
|
<member><xref linkend="sql-dropmaterializedview"/></member>
|
2013-03-04 01:23:31 +01:00
|
|
|
</simplelist>
|
|
|
|
</refsect1>
|
|
|
|
|
|
|
|
</refentry>
|