diff options
Diffstat (limited to 'doc/src')
| -rw-r--r-- | doc/src/sgml/config.sgml | 39 | ||||
| -rw-r--r-- | doc/src/sgml/perform.sgml | 47 |
2 files changed, 40 insertions, 46 deletions
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index 70854ae2986..9cc5281f015 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -2501,16 +2501,19 @@ include_dir 'conf.d' levels. This parameter can only be set at server start. </para> <para> - In <literal>minimal</literal> level, WAL-logging of some bulk - operations can be safely skipped, which can make those - operations much faster (see <xref linkend="populate-pitr"/>). - Operations in which this optimization can be applied include: + In <literal>minimal</literal> level, no information is logged for + permanent relations for the remainder of a transaction that creates or + rewrites them. This can make operations much faster (see + <xref linkend="populate-pitr"/>). Operations that initiate this + optimization include: <simplelist> - <member><command>CREATE TABLE AS</command></member> - <member><command>CREATE INDEX</command></member> + <member><command>ALTER ... SET TABLESPACE</command></member> <member><command>CLUSTER</command></member> - <member><command>COPY</command> into tables that were created or truncated in the same - transaction</member> + <member><command>CREATE TABLE</command></member> + <member><command>REFRESH MATERIALIZED VIEW</command> + (without <option>CONCURRENTLY</option>)</member> + <member><command>REINDEX</command></member> + <member><command>TRUNCATE</command></member> </simplelist> But minimal WAL does not contain enough information to reconstruct the data from a base backup and the WAL logs, so <literal>replica</literal> or @@ -2907,6 +2910,26 @@ include_dir 'conf.d' </listitem> </varlistentry> + <varlistentry id="guc-wal-skip-threshold" xreflabel="wal_skip_threshold"> + <term><varname>wal_skip_threshold</varname> (<type>integer</type>) + <indexterm> + <primary><varname>wal_skip_threshold</varname> configuration parameter</primary> + </indexterm> + </term> + <listitem> + <para> + When <varname>wal_level</varname> is <literal>minimal</literal> and a + transaction commits after creating or rewriting a permanent relation, + this setting determines how to persist the new data. If the data is + smaller than this setting, write it to the WAL log; otherwise, use an + fsync of affected files. Depending on the properties of your storage, + raising or lowering this value might help if such commits are slowing + concurrent transactions. The default is two megabytes + (<literal>2MB</literal>). + </para> + </listitem> + </varlistentry> + <varlistentry id="guc-commit-delay" xreflabel="commit_delay"> <term><varname>commit_delay</varname> (<type>integer</type>) <indexterm> diff --git a/doc/src/sgml/perform.sgml b/doc/src/sgml/perform.sgml index ab090441cfe..58477ac83a8 100644 --- a/doc/src/sgml/perform.sgml +++ b/doc/src/sgml/perform.sgml @@ -1607,8 +1607,8 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse; needs to be written, because in case of an error, the files containing the newly loaded data will be removed anyway. However, this consideration only applies when - <xref linkend="guc-wal-level"/> is <literal>minimal</literal> for - non-partitioned tables as all commands must write WAL otherwise. + <xref linkend="guc-wal-level"/> is <literal>minimal</literal> + as all commands must write WAL otherwise. </para> </sect2> @@ -1708,42 +1708,13 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse; </para> <para> - Aside from avoiding the time for the archiver or WAL sender to - process the WAL data, - doing this will actually make certain commands faster, because they - are designed not to write WAL at all if <varname>wal_level</varname> - is <literal>minimal</literal>. (They can guarantee crash safety more cheaply - by doing an <function>fsync</function> at the end than by writing WAL.) - This applies to the following commands: - <itemizedlist> - <listitem> - <para> - <command>CREATE TABLE AS SELECT</command> - </para> - </listitem> - <listitem> - <para> - <command>CREATE INDEX</command> (and variants such as - <command>ALTER TABLE ADD PRIMARY KEY</command>) - </para> - </listitem> - <listitem> - <para> - <command>ALTER TABLE SET TABLESPACE</command> - </para> - </listitem> - <listitem> - <para> - <command>CLUSTER</command> - </para> - </listitem> - <listitem> - <para> - <command>COPY FROM</command>, when the target table has been - created or truncated earlier in the same transaction - </para> - </listitem> - </itemizedlist> + Aside from avoiding the time for the archiver or WAL sender to process the + WAL data, doing this will actually make certain commands faster, because + they do not to write WAL at all if <varname>wal_level</varname> + is <literal>minimal</literal> and the current subtransaction (or top-level + transaction) created or truncated the table or index they change. (They + can guarantee crash safety more cheaply by doing + an <function>fsync</function> at the end than by writing WAL.) </para> </sect2> |