database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-06-11 20:28:21 +03:00
Code Activity

Add SP-GiST (space-partitioned GiST) index access method.

Browse Source 
SP-GiST is comparable to GiST in flexibility, but supports non-balanced
partitioned search structures rather than balanced trees.  As described at
PGCon 2011, this new indexing structure can beat GiST in both index build
time and query speed for search problems that it is well matched to.

There are a number of areas that could still use improvement, but at this
point the code seems committable.

Teodor Sigaev and Oleg Bartunov, with considerable revisions by Tom Lane
This commit is contained in:
Tom Lane
2011-12-17 16:41:16 -05:00
parent 19fc0fe3ae
commit 8daeb5ddd6
46 changed files with 10395 additions and 101 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
doc/src/sgml/acronyms.sgml
View File

@ -569,6 +569,15 @@
</listitem>
</varlistentry>
<varlistentry>
<term><acronym>SP-GiST</acronym></term>
<listitem>
<para>
<link linkend="SPGiST">Space-Partitioned Generalized Search Tree</link>
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><acronym>SQL</acronym></term>
<listitem>

1
doc/src/sgml/filelist.sgml
View File

@ -82,6 +82,7 @@
<!ENTITY catalogs SYSTEM "catalogs.sgml">
<!ENTITY geqo SYSTEM "geqo.sgml">
<!ENTITY gist SYSTEM "gist.sgml">
<!ENTITY spgist SYSTEM "spgist.sgml">
<!ENTITY gin SYSTEM "gin.sgml">
<!ENTITY planstats SYSTEM "planstats.sgml">
<!ENTITY indexam SYSTEM "indexam.sgml">

35
doc/src/sgml/indices.sgml
View File

@ -116,7 +116,7 @@ CREATE INDEX test1_id_index ON test1 (id);
<para>
<productname>PostgreSQL</productname> provides several index types:
B-tree, Hash, GiST and GIN. Each index type uses a different
B-tree, Hash, GiST, SP-GiST and GIN. Each index type uses a different
algorithm that is best suited to different types of queries.
By default, the <command>CREATE INDEX</command> command creates
B-tree indexes, which fit the most common situations.
@ -253,6 +253,37 @@ SELECT * FROM places ORDER BY location <-> point '(101,456)' LIMIT 10;
to do this is again dependent on the particular operator class being used.
</para>
<para>
<indexterm>
<primary>index</primary>
<secondary>SP-GiST</secondary>
</indexterm>
<indexterm>
<primary>SP-GiST</primary>
<see>index</see>
</indexterm>
SP-GiST indexes, like GiST indexes, offer an infrastructure that supports
various kinds of searches. SP-GiST permits implementation of a wide range
of different non-balanced disk-based data structures, such as quadtrees,
k-d trees, and suffix trees (tries). As an example, the standard distribution of
<productname>PostgreSQL</productname> includes SP-GiST operator classes
for two-dimensional points, which support indexed
queries using these operators:
<simplelist>
<member><literal>&lt;&lt;</literal></member>
<member><literal>&gt;&gt;</literal></member>
<member><literal>~=</literal></member>
<member><literal>&lt;@</literal></member>
<member><literal>&lt;^</literal></member>
<member><literal>&gt;^</literal></member>
</simplelist>
(See <xref linkend="functions-geometry"> for the meaning of
these operators.)
For more information see <xref linkend="SPGiST">.
</para>
<para>
<indexterm>
<primary>index</primary>
@ -263,7 +294,7 @@ SELECT * FROM places ORDER BY location <-> point '(101,456)' LIMIT 10;
<see>index</see>
</indexterm>
GIN indexes are inverted indexes which can handle values that contain more
than one key, arrays for example. Like GiST, GIN can support
than one key, arrays for example. Like GiST and SP-GiST, GIN can support
many different user-defined indexing strategies and the particular
operators with which a GIN index can be used vary depending on the
indexing strategy.

8
doc/src/sgml/mvcc.sgml
View File

@ -525,7 +525,7 @@ ERROR: could not serialize access due to concurrent update
As an example,
consider a table <structname>mytab</>, initially containing:
<screen>
class | value
class | value
-------+-------
1 | 10
1 | 20
@ -1460,7 +1460,7 @@ SELECT pg_advisory_lock(q.id) FROM
<variablelist>
<varlistentry>
<term>
B-tree and <acronym>GiST</acronym> indexes
B-tree, <acronym>GiST</acronym> and <acronym>SP-GiST</acronym> indexes
</term>
<listitem>
<para>
@ -1510,8 +1510,8 @@ SELECT pg_advisory_lock(q.id) FROM
applications; since they also have more features than hash
indexes, they are the recommended index type for concurrent
applications that need to index scalar data. When dealing with
non-scalar data, B-trees are not useful, and GiST or GIN indexes should
be used instead.
non-scalar data, B-trees are not useful, and GiST, SP-GiST or GIN
indexes should be used instead.
</para>
</sect1>
</chapter>

1
doc/src/sgml/postgres.sgml
View File

@ -242,6 +242,7 @@
&geqo;
&indexam;
&gist;
&spgist;
&gin;
&storage;
&bki;

8
doc/src/sgml/ref/alter_opfamily.sgml
View File

@ -144,8 +144,8 @@ ALTER OPERATOR FAMILY <replaceable>name</replaceable> USING <replaceable class="
and hash functions it is not necessary to specify <replaceable
class="parameter">op_type</replaceable> since the function's input
data type(s) are always the correct ones to use. For B-tree sort
support functions and all functions in GiST and GIN operator classes,
it is necessary to specify the operand data type(s) the function
support functions and all functions in GiST, SP-GiST and GIN operator
classes, it is necessary to specify the operand data type(s) the function
is to be used with.
</para>
@ -245,8 +245,8 @@ ALTER OPERATOR FAMILY <replaceable>name</replaceable> USING <replaceable class="
type(s). The name of the operator or function occupying the slot is not
mentioned. Also, for <literal>DROP FUNCTION</> the type(s) to specify
are the input data type(s) the function is intended to support; for
GIN and GiST indexes this might have nothing to do with the actual input
argument types of the function.
GiST, SP-GiST and GIN indexes this might have nothing to do with the actual
input argument types of the function.
</para>
<para>

51
doc/src/sgml/ref/create_index.sgml
View File

@ -57,7 +57,7 @@ CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] [ <replaceable class="parameter">name</
<para>
<productname>PostgreSQL</productname> provides the index methods
B-tree, hash, GiST, and GIN. Users can also define their own index
B-tree, hash, GiST, SP-GiST, and GIN. Users can also define their own index
methods, but that is fairly complicated.
</para>
@ -154,8 +154,8 @@ CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] [ <replaceable class="parameter">name</
<para>
The name of the index method to be used. Choices are
<literal>btree</literal>, <literal>hash</literal>,
<literal>gist</literal>, and <literal>gin</>. The
default method is <literal>btree</literal>.
<literal>gist</literal>, <literal>spgist</> and <literal>gin</>.
The default method is <literal>btree</literal>.
</para>
</listitem>
</varlistentry>
@ -281,12 +281,11 @@ CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] [ <replaceable class="parameter">name</
<para>
The optional <literal>WITH</> clause specifies <firstterm>storage
parameters</> for the index. Each index method has its own set of allowed
storage parameters. The B-tree, hash and GiST index methods all accept a
single parameter:
storage parameters. The B-tree, hash, GiST and SP-GiST index methods all
accept this parameter:
</para>
<variablelist>
<varlistentry>
<term><literal>FILLFACTOR</></term>
<listitem>
@ -307,7 +306,25 @@ CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] [ <replaceable class="parameter">name</
</para>
</listitem>
</varlistentry>
</variablelist>
<para>
GiST indexes additionally accept this parameter:
</para>
<variablelist>
<varlistentry>
<term><literal>BUFFERING</></term>
<listitem>
<para>
Determines whether the buffering build technique described in
<xref linkend="gist-buffering-build"> is used to build the index. With
<literal>OFF</> it is disabled, with <literal>ON</> it is enabled, and
with <literal>AUTO</> it is initially disabled, but turned on
on-the-fly once the index size reaches <xref linkend="guc-effective-cache-size">. The default is <literal>AUTO</>.
</para>
</listitem>
</varlistentry>
</variablelist>
<para>
@ -315,7 +332,6 @@ CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] [ <replaceable class="parameter">name</
</para>
<variablelist>
<varlistentry>
<term><literal>FASTUPDATE</></term>
<listitem>
@ -339,27 +355,6 @@ CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] [ <replaceable class="parameter">name</
</note>
</listitem>
</varlistentry>
</variablelist>
<para>
GiST indexes additionally accept parameter:
</para>
<variablelist>
<varlistentry>
<term><literal>BUFFERING</></term>
<listitem>
<para>
Determines whether the buffering build technique described in
<xref linkend="gist-buffering-build"> is used to build the index. With
<literal>OFF</> it is disabled, with <literal>ON</> it is enabled, and
with <literal>AUTO</> it is initially disabled, but turned on
on-the-fly once the index size reaches <xref linkend="guc-effective-cache-size">. The default is <literal>AUTO</>.
</para>
</listitem>
</varlistentry>
</variablelist>
</refsect2>

4
doc/src/sgml/ref/create_opclass.sgml
View File

@ -172,7 +172,7 @@ CREATE OPERATOR CLASS <replaceable class="parameter">name</replaceable> [ DEFAUL
the input data type(s) of the function (for B-tree comparison functions
and hash functions)
or the class's data type (for B-tree sort support functions and all
functions in GiST and GIN operator classes). These defaults
functions in GiST, SP-GiST and GIN operator classes). These defaults
are correct, and so <replaceable
class="parameter">op_type</replaceable> need not be specified in
<literal>FUNCTION</> clauses, except for the case of a B-tree sort
@ -232,7 +232,7 @@ CREATE OPERATOR CLASS <replaceable class="parameter">name</replaceable> [ DEFAUL
<para>
The data type actually stored in the index. Normally this is
the same as the column data type, but some index methods
(currently GIN and GiST) allow it to be different. The
(currently GiST and GIN) allow it to be different. The
<literal>STORAGE</> clause must be omitted unless the index
method allows a different type to be used.
</para>

3
doc/src/sgml/ref/create_table.sgml
View File

@ -540,7 +540,8 @@ CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } | UNLOGGED ] TABLE [ IF NOT EXI
cannot be used. Although it's allowed, there is little point in using
B-tree or hash indexes with an exclusion constraint, because this
does nothing that an ordinary unique constraint doesn't do better.
So in practice the access method will always be <acronym>GiST</>.
So in practice the access method will always be <acronym>GiST</> or
<acronym>SP-GiST</>.
</para>
<para>

706
doc/src/sgml/spgist.sgml Normal file
View File

@ -0,0 +1,706 @@
<!-- doc/src/sgml/spgist.sgml -->
<chapter id="SPGiST">
<title>SP-GiST Indexes</title>
<indexterm>
<primary>index</primary>
<secondary>SP-GiST</secondary>
</indexterm>
<sect1 id="spgist-intro">
<title>Introduction</title>
<para>
<acronym>SP-GiST</acronym> is an abbreviation for space-partitioned
<acronym>GiST</acronym>. <acronym>SP-GiST</acronym> supports partitioned
search trees, which facilitate development of a wide range of different
non-balanced data structures, such as quad-trees, k-d trees, and suffix
trees (tries). The common feature of these structures is that they
repeatedly divide the search space into partitions that need not be
of equal size. Searches that are well matched to the partitioning rule
can be very fast.
</para>
<para>
These popular data structures were originally developed for in-memory
usage. In main memory, they are usually designed as a set of dynamically
allocated nodes linked by pointers. This is not suitable for direct
storing on disk, since these chains of pointers can be rather long which
would require too many disk accesses. In contrast, disk-based data
structures should have a high fanout to minimize I/O. The challenge
addressed by <acronym>SP-GiST</acronym> is to map search tree nodes to
disk pages in such a way that a search need access only a few disk pages,
even if it traverses many nodes.
</para>
<para>
Like <acronym>GiST</acronym>, <acronym>SP-GiST</acronym> is meant to allow
the development of custom data types with the appropriate access methods,
by an expert in the domain of the data type, rather than a database expert.
</para>
<para>
Some of the information here is derived from Purdue University's
SP-GiST Indexing Project
<ulink url="http://www.cs.purdue.edu/spgist/">web site</ulink>.
The <acronym>SP-GiST</acronym> implementation in
<productname>PostgreSQL</productname> is primarily maintained by Teodor
Sigaev and Oleg Bartunov, and there is more information on their
<!-- URL will be changed -->
<ulink url="http://www.sai.msu.su/~megera/wiki/spgist_dev">web site</ulink>.
</para>
</sect1>
<sect1 id="spgist-extensibility">
<title>Extensibility</title>
<para>
<acronym>SP-GiST</acronym> offers an interface with a high level of
abstraction, requiring the access method developer to implement only
methods specific to a given data type. The <acronym>SP-GiST</acronym> core
is responsible for efficient disk mapping and searching the tree structure.
It also takes care of concurrency and logging considerations.
</para>
<para>
Leaf tuples of an <acronym>SP-GiST</acronym> tree contain values of the
same data type as the indexed column. Leaf tuples at the root level will
always contain the original indexed data value, but leaf tuples at lower
levels might contain only a compressed representation, such as a suffix.
In that case the operator class support functions must be able to
reconstruct the original value using information accumulated from the
inner tuples that are passed through to reach the leaf level.
</para>
<para>
Inner tuples are more complex, since they are branching points in the
search tree. Each inner tuple contains a set of one or more
<firstterm>nodes</>, which represent groups of similar leaf values.
A node contains a downlink that leads to either another, lower-level inner
tuple, or a short list of leaf tuples that all lie on the same index page.
Each node has a <firstterm>label</> that describes it; for example,
in a suffix tree the node label could be the next character of the string
value. Optionally, an inner tuple can have a <firstterm>prefix</> value
that describes all its members. In a suffix tree this could be the common
prefix of the represented strings. The prefix value is not necessarily
really a prefix, but can be any data needed by the operator class;
for example, in a quad-tree it can store the central point that the four
quadrants are measured with respect to. A quad-tree inner tuple would
then also contain four nodes corresponding to the quadrants around this
central point.
</para>
<para>
Some tree algorithms require knowledge of level (or depth) of the current
tuple, so the <acronym>SP-GiST</acronym> core provides the possibility for
operator classes to manage level counting while descending the tree.
There is also support for incrementally reconstructing the represented
value when that is needed.
</para>
<para>
There are five user-defined methods that an index operator class for
<acronym>SP-GiST</acronym> must provide. All five follow the convention
of accepting two <type>internal</> arguments, the first of which is a
pointer to a C struct containing input values for the support method,
while the second argument is a pointer to a C struct where output values
must be placed. Four of the methods just return <type>void</>, since
all their results appear in the output struct; but
<function>leaf_consistent</> additionally returns a <type>boolean</> result.
The methods must not modify any fields of their input structs. In all
cases, the output struct is initialized to zeroes before calling the
user-defined method.
</para>
<para>
The five user-defined methods are:
</para>
<variablelist>
<varlistentry>
<term><function>config</></term>
<listitem>
<para>
Returns static information about the index implementation, including
the datatype OIDs of the prefix and node label data types.
</para>
<para>
The <acronym>SQL</> declaration of the function must look like this:
<programlisting>
CREATE FUNCTION my_config(internal, internal) RETURNS void ...
</programlisting>
The first argument is a pointer to a <structname>spgConfigIn</>
C struct, containing input data for the function.
The second argument is a pointer to a <structname>spgConfigOut</>
C struct, which the function must fill with result data.
<programlisting>
typedef struct spgConfigIn
{
Oid attType; /* Data type to be indexed */
} spgConfigIn;
typedef struct spgConfigOut
{
Oid prefixType; /* Data type of inner-tuple prefixes */
Oid labelType; /* Data type of inner-tuple node labels */
bool longValuesOK; /* Opclass can cope with values &gt; 1 page */
} spgConfigOut;
</programlisting>
<structfield>attType</> is passed in order to support polymorphic
index operator classes; for ordinary fixed-data-type opclasses, it
will always have the same value and so can be ignored.
</para>
<para>
For operator classes that do not use prefixes,
<structfield>prefixType</> can be set to <literal>VOIDOID</>.
Likewise, for operator classes that do not use node labels,
<structfield>labelType</> can be set to <literal>VOIDOID</>.
<structfield>longValuesOK</> should be set true only when the
<structfield>attType</> is of variable length and the operator
class is capable of segmenting long values by repeated suffixing
(see <xref linkend="spgist-limits">).
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><function>choose</></term>
<listitem>
<para>
Chooses a method for inserting a new value into an inner tuple.
</para>
<para>
The <acronym>SQL</> declaration of the function must look like this:
<programlisting>
CREATE FUNCTION my_choose(internal, internal) RETURNS void ...
</programlisting>
The first argument is a pointer to a <structname>spgChooseIn</>
C struct, containing input data for the function.
The second argument is a pointer to a <structname>spgChooseOut</>
C struct, which the function must fill with result data.
<programlisting>
typedef struct spgChooseIn
{
Datum datum; /* original datum to be indexed */
Datum leafDatum; /* current datum to be stored at leaf */
int level; /* current level (counting from zero) */
/* Data from current inner tuple */
bool allTheSame; /* tuple is marked all-the-same? */
bool hasPrefix; /* tuple has a prefix? */
Datum prefixDatum; /* if so, the prefix value */
int nNodes; /* number of nodes in the inner tuple */
Datum *nodeLabels; /* node label values (NULL if none) */
} spgChooseIn;
typedef enum spgChooseResultType
{
spgMatchNode = 1, /* descend into existing node */
spgAddNode, /* add a node to the inner tuple */
spgSplitTuple /* split inner tuple (change its prefix) */
} spgChooseResultType;
typedef struct spgChooseOut
{
spgChooseResultType resultType; /* action code, see above */
union
{
struct /* results for spgMatchNode */
{
int nodeN; /* descend to this node (index from 0) */
int levelAdd; /* increment level by this much */
Datum restDatum; /* new leaf datum */
} matchNode;
struct /* results for spgAddNode */
{
Datum nodeLabel; /* new node's label */
int nodeN; /* where to insert it (index from 0) */
} addNode;
struct /* results for spgSplitTuple */
{
/* Info to form new inner tuple with one node */
bool prefixHasPrefix; /* tuple should have a prefix? */
Datum prefixPrefixDatum; /* if so, its value */
Datum nodeLabel; /* node's label */
/* Info to form new lower-level inner tuple with all old nodes */
bool postfixHasPrefix; /* tuple should have a prefix? */
Datum postfixPrefixDatum; /* if so, its value */
} splitTuple;
} result;
} spgChooseOut;
</programlisting>
<structfield>datum</> is the original datum that was to be inserted
into the index.
<structfield>leafDatum</> is initially the same as
<structfield>datum</>, but can change at lower levels of the tree
if the <function>choose</function> or <function>picksplit</function>
methods change it. When the insertion search reaches a leaf page,
the current value of <structfield>leafDatum</> is what will be stored
in the newly created leaf tuple.
<structfield>level</> is the current inner tuple's level, starting at
zero for the root level.
<structfield>allTheSame</> is true if the current inner tuple is
marked as containing multiple equivalent nodes
(see <xref linkend="spgist-all-the-same">).
<structfield>hasPrefix</> is true if the current inner tuple contains
a prefix; if so,
<structfield>prefixDatum</> is its value.
<structfield>nNodes</> is the number of child nodes contained in the
inner tuple, and
<structfield>nodeLabels</> is an array of their label values, or
NULL if there are no labels.
</para>
<para>
The <function>choose</function> function can determine either that
the new value matches one of the existing child nodes, or that a new
child node must be added, or that the new value is inconsistent with
the tuple prefix and so the inner tuple must be split to create a
less restrictive prefix.
</para>
<para>
If the new value matches one of the existing child nodes,
set <structfield>resultType</> to <literal>spgMatchNode</>.
Set <structfield>nodeN</> to the index (from zero) of that node in
the node array.
Set <structfield>levelAdd</> to the increment in
<structfield>level</> caused by descending through that node,
or leave it as zero if the operator class does not use levels.
Set <structfield>restDatum</> to equal <structfield>datum</>
if the operator class does not modify datums from one level to the
next, or otherwise set it to the modified value to be used as
<structfield>leafDatum</> at the next level.
</para>
<para>
If a new child node must be added,
set <structfield>resultType</> to <literal>spgAddNode</>.
Set <structfield>nodeLabel</> to the label to be used for the new
node, and set <structfield>nodeN</> to the index (from zero) at which
to insert the node in the node array.
After the node has been added, the <function>choose</function>
function will be called again with the modified inner tuple;
that call should result in an <literal>spgMatchNode</> result.
</para>
<para>
If the new value is inconsistent with the tuple prefix,
set <structfield>resultType</> to <literal>spgSplitTuple</>.
This action moves all the existing nodes into a new lower-level
inner tuple, and replaces the existing inner tuple with a tuple
having a single node that links to the new lower-level inner tuple.
Set <structfield>prefixHasPrefix</> to indicate whether the new
upper tuple should have a prefix, and if so set
<structfield>prefixPrefixDatum</> to the prefix value. This new
prefix value must be sufficiently less restrictive than the original
to accept the new value to be indexed, and it should be no longer
than the original prefix.
Set <structfield>nodeLabel</> to the label to be used for the
node that will point to the new lower-level inner tuple.
Set <structfield>postfixHasPrefix</> to indicate whether the new
lower-level inner tuple should have a prefix, and if so set
<structfield>postfixPrefixDatum</> to the prefix value. The
combination of these two prefixes and the additional label must
have the same meaning as the original prefix, because there is
no opportunity to alter the node labels that are moved to the new
lower-level tuple, nor to change any child index entries.
After the node has been split, the <function>choose</function>
function will be called again with the replacement inner tuple.
That call will usually result in an <literal>spgAddNode</> result,
since presumably the node label added in the split step will not
match the new value; so after that, there will be a third call
that finally returns <literal>spgMatchNode</> and allows the
insertion to descend to the leaf level.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><function>picksplit</></term>
<listitem>
<para>
Decides how to create a new inner tuple over a set of leaf tuples.
</para>
<para>
The <acronym>SQL</> declaration of the function must look like this:
<programlisting>
CREATE FUNCTION my_picksplit(internal, internal) RETURNS void ...
</programlisting>
The first argument is a pointer to a <structname>spgPickSplitIn</>
C struct, containing input data for the function.
The second argument is a pointer to a <structname>spgPickSplitOut</>
C struct, which the function must fill with result data.
<programlisting>
typedef struct spgPickSplitIn
{
int nTuples; /* number of leaf tuples */
Datum *datums; /* their datums (array of length nTuples) */
int level; /* current level (counting from zero) */
} spgPickSplitIn;
typedef struct spgPickSplitOut
{
bool hasPrefix; /* new inner tuple should have a prefix? */
Datum prefixDatum; /* if so, its value */
int nNodes; /* number of nodes for new inner tuple */
Datum *nodeLabels; /* their labels (or NULL for no labels) */
int *mapTuplesToNodes; /* node index for each leaf tuple */
Datum *leafTupleDatums; /* datum to store in each new leaf tuple */
} spgPickSplitOut;
</programlisting>
<structfield>nTuples</> is the number of leaf tuples provided.
<structfield>datums</> is an array of their datum values.
<structfield>level</> is the current level that all the leaf tuples
share, which will become the level of the new inner tuple.
</para>
<para>
Set <structfield>hasPrefix</> to indicate whether the new inner
tuple should have a prefix, and if so set
<structfield>prefixDatum</> to the prefix value.
Set <structfield>nNodes</> to indicate the number of nodes that
the new inner tuple will contain, and
set <structfield>nodeLabels</> to an array of their label values.
(If the nodes do not require labels, set <structfield>nodeLabels</>
to NULL; see <xref linkend="spgist-null-labels"> for details.)
Set <structfield>mapTuplesToNodes</> to an array that gives the index
(from zero) of the node that each leaf tuple should be assigned to.
Set <structfield>leafTupleDatums</> to an array of the values to
be stored in the new leaf tuples (these will be the same as the
input <structfield>datums</> if the operator class does not modify
datums from one level to the next).
Note that the <function>picksplit</> function is
responsible for palloc'ing the
<structfield>nodeLabels</>, <structfield>mapTuplesToNodes</> and
<structfield>leafTupleDatums</> arrays.
</para>
<para>
If more than one leaf tuple is supplied, it is expected that the
<function>picksplit</> function will classify them into more than
one node; otherwise it is not possible to split the leaf tuples
across multiple pages, which is the ultimate purpose of this
operation. Therefore, if the <function>picksplit</> function
ends up placing all the leaf tuples in the same node, the core
SP-GiST code will override that decision and generate an inner
tuple in which the leaf tuples are assigned at random to several
identically-labeled nodes. Such a tuple is marked
<literal>allTheSame</> to signify that this has happened. The
<function>choose</> and <function>inner_consistent</> functions
must take suitable care with such inner tuples.
See <xref linkend="spgist-all-the-same"> for more information.
</para>
<para>
<function>picksplit</> can be applied to a single leaf tuple only
in the case that the <function>config</> function set
<structfield>longValuesOK</> to true and a larger-than-a-page input
value has been supplied. In this case the point of the operation is
to strip off a prefix and produce a new, shorter leaf datum value.
The call will be repeated until a leaf datum short enough to fit on
a page has been produced. See <xref linkend="spgist-limits"> for
more information.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><function>inner_consistent</></term>
<listitem>
<para>
Returns set of nodes (branches) to follow during tree search.
</para>
<para>
The <acronym>SQL</> declaration of the function must look like this:
<programlisting>
CREATE FUNCTION my_inner_consistent(internal, internal) RETURNS void ...
</programlisting>
The first argument is a pointer to a <structname>spgInnerConsistentIn</>
C struct, containing input data for the function.
The second argument is a pointer to a <structname>spgInnerConsistentOut</>
C struct, which the function must fill with result data.
<programlisting>
typedef struct spgInnerConsistentIn
{
StrategyNumber strategy; /* operator strategy number */
Datum query; /* operator's RHS value */
Datum reconstructedValue; /* value reconstructed at parent */
int level; /* current level (counting from zero) */
/* Data from current inner tuple */
bool allTheSame; /* tuple is marked all-the-same? */
bool hasPrefix; /* tuple has a prefix? */
Datum prefixDatum; /* if so, the prefix value */
int nNodes; /* number of nodes in the inner tuple */
Datum *nodeLabels; /* node label values (NULL if none) */
} spgInnerConsistentIn;
typedef struct spgInnerConsistentOut
{
int nNodes; /* number of child nodes to be visited */
int *nodeNumbers; /* their indexes in the node array */
int *levelAdds; /* increment level by this much for each */
Datum *reconstructedValues; /* associated reconstructed values */
} spgInnerConsistentOut;
</programlisting>
<structfield>strategy</> and
<structfield>query</> describe the index search condition.
<structfield>reconstructedValue</> is the value reconstructed for the
parent tuple; it is <literal>(Datum) 0</> at the root level or if the
<function>inner_consistent</> function did not provide a value at the
parent level.
<structfield>level</> is the current inner tuple's level, starting at
zero for the root level.
<structfield>allTheSame</> is true if the current inner tuple is
marked <quote>all-the-same</>; in this case all the nodes have the
same label (if any) and so either all or none of them match the query
(see <xref linkend="spgist-all-the-same">).
<structfield>hasPrefix</> is true if the current inner tuple contains
a prefix; if so,
<structfield>prefixDatum</> is its value.
<structfield>nNodes</> is the number of child nodes contained in the
inner tuple, and
<structfield>nodeLabels</> is an array of their label values, or
NULL if the nodes do not have labels.
</para>
<para>
<structfield>nNodes</> must be set to the number of child nodes that
need to be visited by the search, and
<structfield>nodeNumbers</> must be set to an array of their indexes.
If the operator class keeps track of levels, set
<structfield>levelAdds</> to an array of the level increments
required when descending to each node to be visited. (Often these
increments will be the same for all the nodes, but that's not
necessarily so, so an array is used.)
If value reconstruction is needed, set
<structfield>reconstructedValues</> to an array of the values
reconstructed for each child node to be visited; otherwise, leave
<structfield>reconstructedValues</> as NULL.
Note that the <function>inner_consistent</> function is
responsible for palloc'ing the
<structfield>nodeNumbers</>, <structfield>levelAdds</> and
<structfield>reconstructedValues</> arrays.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><function>leaf_consistent</></term>
<listitem>
<para>
Returns true if a leaf tuple satisfies a query.
</para>
<para>
The <acronym>SQL</> declaration of the function must look like this:
<programlisting>
CREATE FUNCTION my_leaf_consistent(internal, internal) RETURNS bool ...
</programlisting>
The first argument is a pointer to a <structname>spgLeafConsistentIn</>
C struct, containing input data for the function.
The second argument is a pointer to a <structname>spgLeafConsistentOut</>
C struct, which the function must fill with result data.
<programlisting>
typedef struct spgLeafConsistentIn
{
StrategyNumber strategy; /* operator strategy number */
Datum query; /* operator's RHS value */
Datum reconstructedValue; /* value reconstructed at parent */
int level; /* current level (counting from zero) */
Datum leafDatum; /* datum in leaf tuple */
} spgLeafConsistentIn;
typedef struct spgLeafConsistentOut
{
bool recheck; /* set true if operator must be rechecked */
} spgLeafConsistentOut;
</programlisting>
<structfield>strategy</> and
<structfield>query</> define the index search condition.
<structfield>reconstructedValue</> is the value reconstructed for the
parent tuple; it is <literal>(Datum) 0</> at the root level or if the
<function>inner_consistent</> function did not provide a value at the
parent level.
<structfield>level</> is the current leaf tuple's level, starting at
zero for the root level.
<structfield>leafDatum</> is the key value stored in the current
leaf tuple.
</para>
<para>
The function must return <literal>true</> if the leaf tuple matches the
query, or <literal>false</> if not. In the <literal>true</> case,
<structfield>recheck</> may be set to <literal>true</> if the match
is uncertain and so the operator must be re-applied to the actual heap
tuple to verify the match.
</para>
</listitem>
</varlistentry>
</variablelist>
<para>
All the SP-GiST support methods are normally called in a short-lived
memory context; that is, <varname>CurrentMemoryContext</> will be reset
after processing of each tuple. It is therefore not very important to
worry about pfree'ing everything you palloc. (The <function>config</>
method is an exception: it should try to avoid leaking memory. But
usually the <function>config</> method need do nothing but assign
constants into the passed parameter struct.)
</para>
<para>
If the indexed column is of a collatable data type, the index collation
will be passed to all the support methods, using the standard
<function>PG_GET_COLLATION()</> mechanism.
</para>
</sect1>
<sect1 id="spgist-implementation">
<title>Implementation</title>
<para>
This section covers implementation details and other tricks that are
useful for implementors of <acronym>SP-GiST</acronym> operator classes to
know.
</para>
<sect2 id="spgist-limits">
<title>SP-GiST Limits</title>
<para>
Individual leaf tuples and inner tuples must fit on a single index page
(8KB by default). Therefore, when indexing values of variable-length
data types, long values can only be supported by methods such as suffix
trees, in which each level of the tree includes a prefix that is short
enough to fit on a page, and the final leaf level includes a suffix also
short enough to fit on a page. The operator class should set
<structfield>longValuesOK</> to TRUE only if it is prepared to arrange for
this to happen. Otherwise, the <acronym>SP-GiST</acronym> core will
reject any request to index a value that is too large to fit
on an index page.
</para>
<para>
Likewise, it is the operator class's responsibility that inner tuples
do not grow too large to fit on an index page; this limits the number
of child nodes that can be used in one inner tuple, as well as the
maximum size of a prefix value.
</para>
<para>
Another limitation is that when an inner tuple's node points to a set
of leaf tuples, those tuples must all be in the same index page.
(This is a design decision to reduce seeking and save space in the
links that chain such tuples together.) If the set of leaf tuples
grows too large for a page, a split is performed and an intermediate
inner tuple is inserted. For this to fix the problem, the new inner
tuple <emphasis>must</> divide the set of leaf values into more than one
node group. If the operator class's <function>picksplit</> function
fails to do that, the <acronym>SP-GiST</acronym> core resorts to
extraordinary measures described in <xref linkend="spgist-all-the-same">.
</para>
</sect2>
<sect2 id="spgist-null-labels">
<title>SP-GiST Without Node Labels</title>
<para>
Some tree algorithms use a fixed set of nodes for each inner tuple;
for example, in a quad-tree there are always exactly four nodes
corresponding to the four quadrants around the inner tuple's centroid
point. In such a case the code typically works with the nodes by
number, and there is no need for explicit node labels. To suppress
node labels (and thereby save some space), the <function>picksplit</>
function can return NULL for the <structfield>nodeLabels</> array.
This will in turn result in <structfield>nodeLabels</> being NULL during
subsequent calls to <function>choose</> and <function>inner_consistent</>.
In principle, node labels could be used for some inner tuples and omitted
for others in the same index.
</para>
<para>
When working with an inner tuple having unlabeled nodes, it is an error
for <function>choose</> to return <literal>spgAddNode</>, since the set
of nodes is supposed to be fixed in such cases. Also, there is no
provision for generating an unlabeled node in <literal>spgSplitTuple</>
actions, since it is expected that an <literal>spgAddNode</> action will
be needed as well.
</para>
</sect2>
<sect2 id="spgist-all-the-same">
<title><quote>All-the-same</> Inner Tuples</title>
<para>
The <acronym>SP-GiST</acronym> core can override the results of the
operator class's <function>picksplit</> function when
<function>picksplit</> fails to divide the supplied leaf values into
at least two node categories. When this happens, the new inner tuple
is created with multiple nodes that each have the same label (if any)
that <function>picksplit</> gave to the one node it did use, and the
leaf values are divided at random among these equivalent nodes.
The <literal>allTheSame</> flag is set on the inner tuple to warn the
<function>choose</> and <function>inner_consistent</> functions that the
tuple does not have the node set that they might otherwise expect.
</para>
<para>
When dealing with an <literal>allTheSame</> tuple, a <function>choose</>
result of <literal>spgMatchNode</> is interpreted to mean that the new
value can be assigned to any of the equivalent nodes; the core code will
ignore the supplied <structfield>nodeN</> value and descend into one
of the nodes at random (so as to keep the tree balanced). It is an
error for <function>choose</> to return <literal>spgAddNode</>, since
that would make the nodes not all equivalent; the
<literal>spgSplitTuple</> action must be used if the value to be inserted
doesn't match the existing nodes.
</para>
<para>
When dealing with an <literal>allTheSame</> tuple, the
<function>inner_consistent</> function should return either all or none
of the nodes as targets for continuing the index search, since they are
all equivalent. This may or may not require any special-case code,
depending on how much the <function>inner_consistent</> function normally
assumes about the meaning of the nodes.
</para>
</sect2>
</sect1>
<sect1 id="spgist-examples">
<title>Examples</title>
<para>
The <productname>PostgreSQL</productname> source distribution includes
several examples of index operator classes for
<acronym>SP-GiST</acronym>. The core system currently provides suffix
trees over text columns and two types of trees over points: quad-tree and
k-d tree. Look into <filename>src/backend/access/spgist/</> to see the
code.
</para>
</sect1>
</chapter>

118
doc/src/sgml/xindex.sgml
View File

@ -237,12 +237,59 @@
</table>
<para>
GIN indexes are similar to GiST indexes in flexibility: they don't have a
fixed set of strategies. Instead the support routines of each operator
SP-GiST indexes are similar to GiST indexes in flexibility: they don't have
a fixed set of strategies. Instead the support routines of each operator
class interpret the strategy numbers according to the operator class's
definition. As an example, the strategy numbers used by the built-in
operator classes for arrays are
shown in <xref linkend="xindex-gin-array-strat-table">.
operator classes for points are shown in <xref
linkend="xindex-spgist-point-strat-table">.
</para>
<table tocentry="1" id="xindex-spgist-point-strat-table">
<title>SP-GiST Point Strategies</title>
<tgroup cols="2">
<thead>
<row>
<entry>Operation</entry>
<entry>Strategy Number</entry>
</row>
</thead>
<tbody>
<row>
<entry>strictly left of</entry>
<entry>1</entry>
</row>
<row>
<entry>strictly right of</entry>
<entry>5</entry>
</row>
<row>
<entry>same</entry>
<entry>6</entry>
</row>
<row>
<entry>contained by</entry>
<entry>8</entry>
</row>
<row>
<entry>strictly below</entry>
<entry>10</entry>
</row>
<row>
<entry>strictly above</entry>
<entry>11</entry>
</row>
</tbody>
</tgroup>
</table>
<para>
GIN indexes are similar to GiST and SP-GiST indexes, in that they don't
have a fixed set of strategies either. Instead the support routines of
each operator class interpret the strategy numbers according to the
operator class's definition. As an example, the strategy numbers used by
the built-in operator classes for arrays are shown in
<xref linkend="xindex-gin-array-strat-table">.
</para>
<table tocentry="1" id="xindex-gin-array-strat-table">
@ -434,6 +481,54 @@
</tgroup>
</table>
<para>
SP-GiST indexes require five support functions, as
shown in <xref linkend="xindex-spgist-support-table">.
(For more information see <xref linkend="SPGiST">.)
</para>
<table tocentry="1" id="xindex-spgist-support-table">
<title>SP-GiST Support Functions</title>
<tgroup cols="3">
<thead>
<row>
<entry>Function</entry>
<entry>Description</entry>
<entry>Support Number</entry>
</row>
</thead>
<tbody>
<row>
<entry><function>config</></entry>
<entry>provide basic information about the operator class</entry>
<entry>1</entry>
</row>
<row>
<entry><function>choose</></entry>
<entry>determine how to insert a new value into an inner tuple</entry>
<entry>2</entry>
</row>
<row>
<entry><function>picksplit</></entry>
<entry>determine how to partition a set of values</entry>
<entry>3</entry>
</row>
<row>
<entry><function>inner_consistent</></entry>
<entry>determine which sub-partitions need to be searched for a
query</entry>
<entry>4</entry>
</row>
<row>
<entry><function>leaf_consistent</></entry>
<entry>determine whether key satisfies the
query qualifier</entry>
<entry>5</entry>
</row>
</tbody>
</tgroup>
</table>
<para>
GIN indexes require four support functions, with an optional fifth, as
shown in <xref linkend="xindex-gin-support-table">.
@ -495,9 +590,9 @@
of the comparison function for B-trees, a signed integer. The number
and types of the arguments to each support function are likewise
dependent on the index method. For B-tree and hash the comparison and
hashing support functions
take the same input data types as do the operators included in the operator
class, but this is not the case for most GIN and GiST support functions.
hashing support functions take the same input data types as do the
operators included in the operator class, but this is not the case for
most GiST, SP-GiST, and GIN support functions.
</para>
</sect2>
@ -876,9 +971,10 @@ ALTER OPERATOR FAMILY integer_ops USING btree ADD
</para>
<para>
GIN and GiST indexes do not have any explicit notion of cross-data-type
operations. The set of operators supported is just whatever the primary
support functions for a given operator class can handle.
GiST, SP-GiST, and GIN indexes do not have any explicit notion of
cross-data-type operations. The set of operators supported is just
whatever the primary support functions for a given operator class can
handle.
</para>
<note>
@ -1045,7 +1141,7 @@ SELECT * FROM table WHERE integer_column &lt; 4;
the index is guaranteed to return all the required rows, plus perhaps
some additional rows, which can be eliminated by performing the original
operator invocation. The index methods that support lossy searches
(currently, GiST and GIN) allow the support functions of individual
(currently, GiST, SP-GiST and GIN) allow the support functions of individual
operator classes to set the recheck flag, and so this is essentially an
operator-class feature.
</para>