GiST, SP-GiST, GIN, BRIN, and the extension <link
   linkend="bloom">bloom</link>.
   Each index type uses a different
   algorithm that is best suited to different types of indexable clauses.
   By default, the <link linkend="sql-createindex"><command>CREATE
   INDEX</command></link> command creates
   B-tree indexes, which fit the most common situations.
   The other index types are selected by writing the keyword
   <literal>USING</literal> followed by the index type name.
   For example, to create a Hash index:
<programlisting>
CREATE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable> USING HASH (<replaceable>column</replaceable>);
</programlisting>
  </para>

  <sect2 id="indexes-types-btree">
   <title>B-Tree</title>

   <indexterm>
    <primary>index</primary>
    <secondary>B-Tree</secondary>
   </indexterm>
   <indexterm>
    <primary>B-Tree</primary>
    <see>index</see>
   </indexterm>

  <para>
   B-trees can handle equality and range queries on data that can be sorted
   into some ordering.
   In particular, the <productname>PostgreSQL</productname> query planner
   will consider using a B-tree index whenever an indexed column is
   involved in a comparison using one of these operators:

<synopsis>
&lt; &nbsp; &lt;= &nbsp; = &nbsp; &gt;= &nbsp; &gt;
</synopsis>

   Constructs equivalent to combinations of these operators, such as
   <literal>BETWEEN</literal> and <literal>IN</literal>, can also be implemented with
   a B-tree index search.  Also, an <literal>IS NULL</literal> or <literal>IS NOT
   NULL</literal> condition on an index column can be used with a B-tree index.
  </para>

  <para>
   The optimizer can also use a B-tree index for queries involving the
   pattern matching operators <literal>LIKE</literal> and <literal>~</literal>
   <emphasis>if</emphasis> the pattern is a constant and is anchored to
   the beginning of the string &mdash; for example, <literal>col LIKE
   'foo%'</literal> or <literal>col ~ '^foo'</literal>, but not
   <literal>col LIKE '%bar'</literal>. However, if your database does not
   use the C locale you will need to create the index with a special
   operator class to support indexing of pattern-matching queries; see
   <xref linkend="indexes-opclass"/> below. It is also possible to use
   B-tree indexes for <literal>ILIKE</literal> and
   <literal>~*</literal>, but only if the pattern starts with
   non-alphabetic characters, i.e., characters that are not affected by
   upper/lower case conversion.
  </para>

  <para>
   B-tree indexes can also be used to retrieve data in sorted order.
   This is not always faster than a simple scan and sort, but it is
   often helpful.
  </para>
  </sect2>

  <sect2 id="indexes-types-hash">
   <title>Hash</title>

   <indexterm>
    <primary>index</primary>
    <secondary>hash</secondary>
   </indexterm>
   <indexterm>
    <primary>hash</primary>
    <see>index</see>
   </indexterm>

  <para>
   Hash indexes store a 32-bit hash code derived from the
   value of the indexed column. Hence,
   such indexes can only handle simple equality comparisons.
   The query planner will consider using a hash index whenever an
   indexed column is involved in a comparison using the
   equal operator:

<synopsis>
=
</synopsis>
  </para>
  </sect2>

  <sect2 id="indexes-type-gist">
   <title>GiST</title>

   <indexterm>
    <primary>index</primary>
    <secondary>GiST</secondary>
   </indexterm>
   <indexterm>
    <primary>GiST</primary>
    <see>index</see>
   </indexterm>

  <para>
   GiST indexes are not a single kind of index, but rather an infrastructure
   within which many different indexing strategies can be implemented.
   Accordingly, the particular operators with which a GiST index can be
   used vary depending on the indexing strategy (the <firstterm>operator
   class</firstterm>).  As an example, the standard distribution of
   <productname>PostgreSQL</productname> includes GiST operator classes
   for several two-dimensional