new pages are filled with data, page ranges that are already
   summarized will cause the summary information to be updated with data
   from the new tuples.
   When a new page is created that does not fall within the last
   summarized range, the range that the new page belongs to
   does not automatically acquire a summary tuple;
   those tuples remain unsummarized until a summarization run is
   invoked later, creating the initial summary for that range.
  </para>

  <para>
   There are several ways to trigger the initial summarization of a page range.
   If the table is vacuumed, either manually or by
   <link linkend="autovacuum">autovacuum</link>, all existing unsummarized
   page ranges are summarized.
   Also, if the index's
   <xref linkend="index-reloption-autosummarize"/> parameter is enabled,
   which it isn't by default,
   whenever autovacuum runs in that database, summarization will occur for all
   unsummarized page ranges that have been filled,
   regardless of whether the table itself is processed by autovacuum; see below.
  </para>

  <para>
   Lastly, the following functions can be used (while these functions run,
   <xref linkend="guc-search-path"/> is temporarily changed to
   <literal>pg_catalog, pg_temp</literal>):
   <simplelist>
    <member>
     <function>brin_summarize_new_values(regclass)</function>
     which summarizes all unsummarized ranges;
    </member>
    <member>
     <function>brin_summarize_range(regclass, bigint)</function>
     which summarizes only the range containing the given page,
     if it is unsummarized.
    </member>
   </simplelist>
  </para>

  <para>
   When autosummarization is enabled, a request is sent to
   <literal>autovacuum</literal> to execute a targeted summarization
   for a block range when an insertion is detected for the first item
   of the first page of the next block range,
   to be fulfilled the next time an autovacuum
   worker finishes running in the
   same database.  If the request queue is full, the request is not recorded
   and a message is sent to the server log:
<screen>
LOG:  request for BRIN range summarization for index "brin_wi_idx" page 128 was not recorded
</screen>
   When this happens, the range will remain unsummarized until the next
   regular vacuum run on the table, or one of the functions mentioned above
   are invoked.
  </para>

  <para>
   Conversely, a range can be de-summarized using the
   <function>brin_desummarize_range(regclass, bigint)</function> function,
   which is useful when the index tuple is no longer a very good
   representation because the existing values have changed.
   See <xref linkend="functions-admin-index"/> for details.
  </para>

 </sect3>
</sect2>

<sect2 id="brin-builtin-opclasses">
 <title>Built-in Operator Classes</title>

 <para>
  The core <productname>PostgreSQL</productname> distribution
  includes the <acronym>BRIN</acronym> operator classes shown in
  <xref linkend="brin-builtin-opclasses-table"/>.
 </para>

 <para>
  The <firstterm>minmax</firstterm>
  operator classes store the minimum and the maximum values appearing
  in the indexed column within the range.  The <firstterm>inclusion</firstterm>
  operator classes store a value which includes the values in the indexed
  column within the range.  The <firstterm>bloom</firstterm> operator
  classes build a Bloom filter for all values in the range.  The
  <firstterm>minmax-multi</firstterm> operator classes store multiple
  minimum and maximum values, representing values appearing in the indexed
  column within the range.
 </para>

 <table id="brin-builtin-opclasses-table">
  <title>Built-in <acronym>BRIN</acronym> Operator Classes</title>
  <tgroup cols="2">
   <thead>
    <row>
     <entry>Name</entry>
     <entry>Indexable Operators</entry>
    </row>
   </thead>
   <tbody>
    <row>
     <entry valign="middle" morerows="4"><literal>bit_minmax_ops</literal></entry>
     <entry><literal>= (bit,bit)</literal></entry>
    </row>
    <row><entry><literal>&lt;