mirror of
https://github.com/postgres/postgres.git
synced 2025-06-26 12:21:12 +03:00
Add external documentation for KNNGIST.
This commit is contained in:
@ -78,7 +78,7 @@
|
||||
|
||||
<para>
|
||||
All it takes to get a <acronym>GiST</acronym> access method up and running
|
||||
is to implement seven user-defined methods, which define the behavior of
|
||||
is to implement several user-defined methods, which define the behavior of
|
||||
keys in the tree. Of course these methods have to be pretty fancy to
|
||||
support fancy queries, but for all the standard queries (B-trees,
|
||||
R-trees, etc.) they're relatively straightforward. In short,
|
||||
@ -93,12 +93,13 @@
|
||||
|
||||
<para>
|
||||
There are seven methods that an index operator class for
|
||||
<acronym>GiST</acronym> must provide. Correctness of the index is ensured
|
||||
<acronym>GiST</acronym> must provide, and an eighth that is optional.
|
||||
Correctness of the index is ensured
|
||||
by proper implementation of the <function>same</>, <function>consistent</>
|
||||
and <function>union</> methods, while efficiency (size and speed) of the
|
||||
index will depend on the <function>penalty</> and <function>picksplit</>
|
||||
methods.
|
||||
The remaining two methods are <function>compress</> and
|
||||
The remaining two basic methods are <function>compress</> and
|
||||
<function>decompress</>, which allow an index to have internal tree data of
|
||||
a different type than the data it indexes. The leaves are to be of the
|
||||
indexed data type, while the other tree nodes can be of any C struct (but
|
||||
@ -106,6 +107,9 @@
|
||||
see about <literal>varlena</> for variable sized data). If the tree's
|
||||
internal data type exists at the SQL level, the <literal>STORAGE</> option
|
||||
of the <command>CREATE OPERATOR CLASS</> command can be used.
|
||||
The optional eighth method is <function>distance</>, which is needed
|
||||
if the operator class wishes to support ordered scans (nearest-neighbor
|
||||
searches).
|
||||
</para>
|
||||
|
||||
<variablelist>
|
||||
@ -567,6 +571,73 @@ my_same(PG_FUNCTION_ARGS)
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><function>distance</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Given an index entry <literal>p</> and a query value <literal>q</>,
|
||||
this function determines the index entry's
|
||||
<quote>distance</> from the query value. This function must be
|
||||
supplied if the operator class contains any ordering operators.
|
||||
A query using the ordering operator will be implemented by returning
|
||||
index entries with the smallest <quote>distance</> values first,
|
||||
so the results must be consistent with the operator's semantics.
|
||||
For a leaf index entry the result just represents the distance to
|
||||
the index entry; for an internal tree node, the result must be the
|
||||
smallest distance that any child entry could have.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The <acronym>SQL</> declaration of the function must look like this:
|
||||
|
||||
<programlisting>
|
||||
CREATE OR REPLACE FUNCTION my_distance(internal, data_type, smallint, oid)
|
||||
RETURNS float8
|
||||
AS 'MODULE_PATHNAME'
|
||||
LANGUAGE C STRICT;
|
||||
</programlisting>
|
||||
|
||||
And the matching code in the C module could then follow this skeleton:
|
||||
|
||||
<programlisting>
|
||||
Datum my_distance(PG_FUNCTION_ARGS);
|
||||
PG_FUNCTION_INFO_V1(my_distance);
|
||||
|
||||
Datum
|
||||
my_distance(PG_FUNCTION_ARGS)
|
||||
{
|
||||
GISTENTRY *entry = (GISTENTRY *) PG_GETARG_POINTER(0);
|
||||
data_type *query = PG_GETARG_DATA_TYPE_P(1);
|
||||
StrategyNumber strategy = (StrategyNumber) PG_GETARG_UINT16(2);
|
||||
/* Oid subtype = PG_GETARG_OID(3); */
|
||||
data_type *key = DatumGetDataType(entry->key);
|
||||
double retval;
|
||||
|
||||
/*
|
||||
* determine return value as a function of strategy, key and query.
|
||||
*/
|
||||
|
||||
PG_RETURN_FLOAT8(retval);
|
||||
}
|
||||
</programlisting>
|
||||
|
||||
The arguments to the <function>distance</> function are identical to
|
||||
the arguments of the <function>consistent</> function, except that no
|
||||
recheck flag is used. The distance to a leaf index entry must always
|
||||
be determined exactly, since there is no way to re-order the tuples
|
||||
once they are returned. Some approximation is allowed when determining
|
||||
the distance to an internal tree node, so long as the result is never
|
||||
greater than any child's actual distance. Thus, for example, distance
|
||||
to a bounding box is usually sufficient in geometric applications. The
|
||||
result value can be any finite <type>float8</> value. (Infinity and
|
||||
minus infinity are used internally to handle cases such as nulls, so it
|
||||
is not recommended that <function>distance</> functions return these
|
||||
values.)
|
||||
</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
</variablelist>
|
||||
|
||||
</sect1>
|
||||
|
Reference in New Issue
Block a user