linkend="guc-superuser-reserved-connections"/> limits.
   </para>

   <para>
    Tables whose <structfield>relfrozenxid</structfield> value is more than
    <xref linkend="guc-autovacuum-freeze-max-age"/> transactions old are always
    vacuumed (this also applies to those tables whose freeze max age has
    been modified via storage parameters; see below).  Otherwise, if the
    number of tuples obsoleted since the last
    <command>VACUUM</command> exceeds the <quote>vacuum threshold</quote>, the
    table is vacuumed.  The vacuum threshold is defined as:
<programlisting>
vacuum threshold = Minimum(vacuum max threshold, vacuum base threshold + vacuum scale factor * number of tuples)
</programlisting>
    where the vacuum max threshold is
    <xref linkend="guc-autovacuum-vacuum-max-threshold"/>,
    the vacuum base threshold is
    <xref linkend="guc-autovacuum-vacuum-threshold"/>,
    the vacuum scale factor is
    <xref linkend="guc-autovacuum-vacuum-scale-factor"/>,
    and the number of tuples is
    <structname>pg_class</structname>.<structfield>reltuples</structfield>.
   </para>

   <para>
    The table is also vacuumed if the number of tuples inserted since the last
    vacuum has exceeded the defined insert threshold, which is defined as:
<programlisting>
vacuum insert threshold = vacuum base insert threshold + vacuum insert scale factor * number of tuples
</programlisting>
    where the vacuum insert base threshold is
    <xref linkend="guc-autovacuum-vacuum-insert-threshold"/>,
    and vacuum insert scale factor is
    <xref linkend="guc-autovacuum-vacuum-insert-scale-factor"/>.
    Such vacuums may allow portions of the table to be marked as
    <firstterm>all visible</firstterm> and also allow tuples to be frozen, which
    can reduce the work required in subsequent vacuums.
    For tables which receive <command>INSERT</command> operations but no or
    almost no <command>UPDATE</command>/<command>DELETE</command> operations,
    it may be beneficial to lower the table's
    <xref linkend="reloption-autovacuum-freeze-min-age"/> as this may allow
    tuples to be frozen by earlier vacuums.  The number of obsolete tuples and
    the number of inserted tuples are obtained from the cumulative statistics system;
    it is an eventually-consistent count updated by each <command>UPDATE</command>,
    <command>DELETE</command> and <command>INSERT</command> operation.
    If the <structfield>relfrozenxid</structfield> value of the table
    is more than <varname>vacuum_freeze_table_age</varname> transactions old,
    an aggressive vacuum is performed to freeze old tuples and advance
    <structfield>relfrozenxid</structfield>.
   </para>

   <para>
    For analyze, a similar condition is used: the threshold, defined as:
<programlisting>
analyze threshold = analyze base threshold + analyze scale factor * number of tuples
</programlisting>
    is compared to the total number of tuples inserted, updated, or deleted
    since the last <command>ANALYZE</command>.
   </para>

   <para>
    Partitioned tables do not directly store tuples and consequently
    are not processed by autovacuum.  (Autovacuum does process table
    partitions just like other tables.)  Unfortunately, this means that
    autovacuum does  not run <command>ANALYZE</command> on partitioned
    tables, and this can cause suboptimal plans for queries that reference
    partitioned table statistics.  You can work around this problem by
    manually running <command>ANALYZE</command> on partitioned tables
    when they are first populated, and again whenever the distribution
    of data in their partitions changes significantly.
   </para>

   <para>
    Temporary tables cannot be accessed by autovacuum.  Therefore,
    appropriate vacuum and analyze operations should be performed via
    session SQL commands.
   </para>

   <para>
    The default thresholds and scale factors are taken from
    <filename>postgresql.conf</filename>, but it is possible to override