</listitem>
   </varlistentry>

   <varlistentry id="reloption-toast-tuple-target" xreflabel="toast_tuple_target">
    <term><literal>toast_tuple_target</literal> (<type>integer</type>)
    <indexterm>
     <primary><varname>toast_tuple_target</varname> storage parameter</primary>
    </indexterm>
    </term>
    <listitem>
     <para>
      The toast_tuple_target specifies the minimum tuple length required before
      we try to compress and/or move long column values into TOAST tables, and
      is also the target length we try to reduce the length below once toasting
      begins. This affects columns marked as External (for move),
      Main (for compression), or Extended (for both) and applies only to new
      tuples. There is no effect on existing rows.
      By default this parameter is set to allow at least 4 tuples per block,
      which with the default block size will be 2040 bytes. Valid values are
      between 128 bytes and the (block size - header), by default 8160 bytes.
      Changing this value may not be useful for very short or very long rows.
      Note that the default setting is often close to optimal, and
      it is possible that setting this parameter could have negative
      effects in some cases.
      This parameter cannot be set for TOAST tables.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry id="reloption-parallel-workers" xreflabel="parallel_workers">
    <term><literal>parallel_workers</literal> (<type>integer</type>)
     <indexterm>
     <primary><varname>parallel_workers</varname> storage parameter</primary>
    </indexterm>
    </term>
    <listitem>
     <para>
      This sets the number of workers that should be used to assist a parallel
      scan of this table.  If not set, the system will determine a value based
      on the relation size.  The actual number of workers chosen by the planner
      or by utility statements that use parallel scans may be less, for example
      due to the setting of <xref linkend="guc-max-worker-processes"/>.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry id="reloption-autovacuum-enabled" xreflabel="autovacuum_enabled">
    <term><literal>autovacuum_enabled</literal>, <literal>toast.autovacuum_enabled</literal> (<type>boolean</type>)
    <indexterm>
     <primary><varname>autovacuum_enabled</varname> storage parameter</primary>
    </indexterm>
    </term>
    <listitem>
     <para>
     Enables or disables the autovacuum daemon for a particular table.
     If true, the autovacuum daemon will perform automatic <command>VACUUM</command>
     and/or <command>ANALYZE</command> operations on this table following the rules
     discussed in <xref linkend="autovacuum"/>.
     If false, this table will not be autovacuumed, except to prevent
     transaction ID wraparound. See <xref linkend="vacuum-for-wraparound"/> for
     more about wraparound prevention.
     Note that the autovacuum daemon does not run at all (except to prevent
     transaction ID wraparound) if the <xref linkend="guc-autovacuum"/>
     parameter is false; setting individual tables' storage parameters does
     not override that.  Therefore there is seldom much point in explicitly
     setting this storage parameter to <literal>true</literal>, only
     to <literal>false</literal>.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry id="reloption-vacuum-index-cleanup" xreflabel="vacuum_index_cleanup">
    <term><literal>vacuum_index_cleanup</literal>, <literal>toast.vacuum_index_cleanup</literal> (<type>enum</type>)
    <indexterm>
     <primary><varname>vacuum_index_cleanup</varname> storage parameter</primary>
    </indexterm>
    </term>
    <listitem>
     <para>
      Forces or disables index cleanup when <command>VACUUM</command>
      is run on this table.  The default value is
      <literal>AUTO</literal>.  With <literal>OFF</literal>, index
      cleanup is disabled, with <literal>ON</literal> it is enabled,
      and with <literal>AUTO</literal>