aboutsummaryrefslogtreecommitdiff
path: root/doc/src
diff options
context:
space:
mode:
authorAlvaro Herrera <alvherre@alvh.no-ip.org>2017-04-01 14:00:53 -0300
committerAlvaro Herrera <alvherre@alvh.no-ip.org>2017-04-01 14:00:53 -0300
commit7526e10224f0792201e99631567bbe44492bbde4 (patch)
tree0f571916efeee40d0f94df78a3478966ef4f1e7b /doc/src
parent7220c7b3e5c847227fbfe53bbaca326044674a6c (diff)
downloadpostgresql-7526e10224f0792201e99631567bbe44492bbde4.tar.gz
postgresql-7526e10224f0792201e99631567bbe44492bbde4.zip
BRIN auto-summarization
Previously, only VACUUM would cause a page range to get initially summarized by BRIN indexes, which for some use cases takes too much time since the inserts occur. To avoid the delay, have brininsert request a summarization run for the previous range as soon as the first tuple is inserted into the first page of the next range. Autovacuum is in charge of processing these requests, after doing all the regular vacuuming/ analyzing work on tables. This doesn't impose any new tasks on autovacuum, because autovacuum was already in charge of doing summarizations. The only actual effect is to change the timing, i.e. that it occurs earlier. For this reason, we don't go any great lengths to record these requests very robustly; if they are lost because of a server crash or restart, they will happen at a later time anyway. Most of the new code here is in autovacuum, which can now be told about "work items" to process. This can be used for other things such as GIN pending list cleaning, perhaps visibility map bit setting, both of which are currently invoked during vacuum, but do not really depend on vacuum taking place. The requests are at the page range level, a granularity for which we did not have SQL-level access; we only had index-level summarization requests via brin_summarize_new_values(). It seems reasonable to add SQL-level access to range-level summarization too, so add a function brin_summarize_range() to do that. Authors: Álvaro Herrera, based on sketch from Simon Riggs. Reviewed-by: Thomas Munro. Discussion: https://postgr.es/m/20170301045823.vneqdqkmsd4as4ds@alvherre.pgsql
Diffstat (limited to 'doc/src')
-rw-r--r--doc/src/sgml/brin.sgml9
-rw-r--r--doc/src/sgml/func.sgml10
-rw-r--r--doc/src/sgml/ref/create_index.sgml12
3 files changed, 27 insertions, 4 deletions
diff --git a/doc/src/sgml/brin.sgml b/doc/src/sgml/brin.sgml
index 5bf11dc2d15..5140a38baad 100644
--- a/doc/src/sgml/brin.sgml
+++ b/doc/src/sgml/brin.sgml
@@ -74,9 +74,14 @@
tuple; those tuples remain unsummarized until a summarization run is
invoked later, creating initial summaries.
This process can be invoked manually using the
- <function>brin_summarize_new_values(regclass)</function> function,
- or automatically when <command>VACUUM</command> processes the table.
+ <function>brin_summarize_range(regclass, bigint)</function> or
+ <function>brin_summarize_new_values(regclass)</function> functions;
+ automatically when <command>VACUUM</command> processes the table;
+ or by automatic summarization executed by autovacuum, as insertions
+ occur. (This last trigger is disabled by default and can be enabled
+ with the <literal>autosummarize</literal> parameter.)
</para>
+
</sect2>
</sect1>
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 6887eabd0e9..25c18d107c8 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -19685,6 +19685,13 @@ postgres=# SELECT * FROM pg_walfile_name_offset(pg_stop_backup());
</row>
<row>
<entry>
+ <literal><function>brin_summarize_range(<parameter>index</> <type>regclass</>, <parameter>blockNumber</> <type>bigint</type>)</function></literal>
+ </entry>
+ <entry><type>integer</type></entry>
+ <entry>summarize the page range covering the given block, if not already summarized</entry>
+ </row>
+ <row>
+ <entry>
<literal><function>gin_clean_pending_list(<parameter>index</> <type>regclass</>)</function></literal>
</entry>
<entry><type>bigint</type></entry>
@@ -19700,7 +19707,8 @@ postgres=# SELECT * FROM pg_walfile_name_offset(pg_stop_backup());
that are not currently summarized by the index; for any such range
it creates a new summary index tuple by scanning the table pages.
It returns the number of new page range summaries that were inserted
- into the index.
+ into the index. <function>brin_summarize_range</> does the same, except
+ it only summarizes the range that covers the given block number.
</para>
<para>
diff --git a/doc/src/sgml/ref/create_index.sgml b/doc/src/sgml/ref/create_index.sgml
index 7163b032b1b..83ee7d3f252 100644
--- a/doc/src/sgml/ref/create_index.sgml
+++ b/doc/src/sgml/ref/create_index.sgml
@@ -382,7 +382,7 @@ CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] [ [ IF NOT EXISTS ] <replaceable class=
</variablelist>
<para>
- <acronym>BRIN</> indexes accept a different parameter:
+ <acronym>BRIN</> indexes accept different parameters:
</para>
<variablelist>
@@ -396,6 +396,16 @@ CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] [ [ IF NOT EXISTS ] <replaceable class=
</para>
</listitem>
</varlistentry>
+
+ <varlistentry>
+ <term><literal>autosummarize</></term>
+ <listitem>
+ <para>
+ Defines whether a summarization run is invoked for the previous page
+ range whenever an insertion is detected on the next one.
+ </para>
+ </listitem>
+ </varlistentry>
</variablelist>
</refsect2>