diff options
author | Alvaro Herrera <alvherre@alvh.no-ip.org> | 2017-04-01 14:00:53 -0300 |
---|---|---|
committer | Alvaro Herrera <alvherre@alvh.no-ip.org> | 2017-04-01 14:00:53 -0300 |
commit | 7526e10224f0792201e99631567bbe44492bbde4 (patch) | |
tree | 0f571916efeee40d0f94df78a3478966ef4f1e7b /doc/src | |
parent | 7220c7b3e5c847227fbfe53bbaca326044674a6c (diff) | |
download | postgresql-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.sgml | 9 | ||||
-rw-r--r-- | doc/src/sgml/func.sgml | 10 | ||||
-rw-r--r-- | doc/src/sgml/ref/create_index.sgml | 12 |
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> |