<term><literal>fillfactor</literal> (<type>integer</type>)
     <indexterm>
      <primary><varname>fillfactor</varname> storage parameter</primary>
     </indexterm>
    </term>
    <listitem>
     <para>
      Controls how full
      the index method will try to pack index pages.  For B-trees, leaf pages
      are filled to this percentage during initial index builds, and also
      when extending the index at the right (adding new largest key values).
      If pages
      subsequently become completely full, they will be split, leading to
      fragmentation of the on-disk index structure.  B-trees use a default
      fillfactor of 90, but any integer value from 10 to 100 can be selected.
     </para>
     <para>
      B-tree indexes on tables where many inserts and/or updates are
      anticipated can benefit from lower fillfactor settings at
      <command>CREATE INDEX</command> time (following bulk loading into the
      table).  Values in the range of 50 - 90 can usefully <quote>smooth
       out</quote> the <emphasis>rate</emphasis> of page splits during the
      early life of the B-tree index (lowering fillfactor like this may even
      lower the absolute number of page splits, though this effect is highly
      workload dependent).  The B-tree bottom-up index deletion technique
      described in <xref linkend="btree-deletion"/> is dependent on having
      some <quote>extra</quote> space on pages to store <quote>extra</quote>
      tuple versions, and so can be affected by fillfactor (though the effect
      is usually not significant).
     </para>
     <para>
      In other specific cases it might be useful to increase fillfactor to
      100 at <command>CREATE INDEX</command> time as a way of maximizing
      space utilization.  You should only consider this when you are
      completely sure that the table is static (i.e. that it will never be
      affected by either inserts or updates).  A fillfactor setting of 100
      otherwise risks <emphasis>harming</emphasis> performance: even a few
      updates or inserts will cause a sudden flood of page splits.
     </para>
     <para>
      The other index methods use fillfactor in different but roughly
      analogous ways; the default fillfactor varies between methods.
     </para>
    </listitem>
   </varlistentry>
   </variablelist>

   <para>
    B-tree indexes additionally accept this parameter:
   </para>

   <variablelist>
   <varlistentry id="index-reloption-deduplicate-items" xreflabel="deduplicate_items">
    <term><literal>deduplicate_items</literal> (<type>boolean</type>)
     <indexterm>
      <primary><varname>deduplicate_items</varname> storage parameter</primary>
     </indexterm>
    </term>
    <listitem>
    <para>
      Controls usage of the B-tree deduplication technique described
      in <xref linkend="btree-deduplication"/>.  Set to
      <literal>ON</literal> or <literal>OFF</literal> to enable or
      disable the optimization.  (Alternative spellings of
      <literal>ON</literal> and <literal>OFF</literal> are allowed as
      described in <xref linkend="config-setting"/>.) The default is
      <literal>ON</literal>.
    </para>

    <note>
     <para>
      Turning <literal>deduplicate_items</literal> off via
      <command>ALTER INDEX</command> prevents future insertions from
      triggering deduplication, but does not in itself make existing
      posting list tuples use the standard tuple representation.
     </para>
    </note>
    </listitem>
   </varlistentry>
   </variablelist>

   <para>
    GiST indexes additionally accept this parameter:
   </para>

   <variablelist>
   <varlistentry id="index-reloption-buffering" xreflabel="buffering">
    <term><literal>buffering</literal> (<type>enum</type>)
     <indexterm>
      <primary><varname>buffering</varname> storage parameter</primary>
     </indexterm>
    </term>
    <listitem>
    <para>
     Controls whether the buffered build technique described in
     <xref linkend="gist-buffering-build"/>