1
0
mirror of https://github.com/postgres/postgres.git synced 2025-09-02 04:21:28 +03:00

Create a "sort support" interface API for faster sorting.

This patch creates an API whereby a btree index opclass can optionally
provide non-SQL-callable support functions for sorting.  In the initial
patch, we only use this to provide a directly-callable comparator function,
which can be invoked with a bit less overhead than the traditional
SQL-callable comparator.  While that should be of value in itself, the real
reason for doing this is to provide a datatype-extensible framework for
more aggressive optimizations, as in Peter Geoghegan's recent work.

Robert Haas and Tom Lane
This commit is contained in:
Tom Lane
2011-12-07 00:18:38 -05:00
parent d2a662182e
commit c6e3ac11b6
30 changed files with 869 additions and 421 deletions

View File

@@ -169,13 +169,14 @@ CREATE OPERATOR CLASS <replaceable class="parameter">name</replaceable> [ DEFAUL
<para>
In a <literal>FUNCTION</> clause, the operand data type(s) the
function is intended to support, if different from
the input data type(s) of the function (for B-tree and hash indexes)
or the class's data type (for GIN and GiST indexes). These defaults
are always correct, so there is no point in specifying <replaceable
class="parameter">op_type</replaceable> in a <literal>FUNCTION</> clause
in <command>CREATE OPERATOR CLASS</>, but the option is provided
for consistency with the comparable syntax in
<command>ALTER OPERATOR FAMILY</>.
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
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
support function that is meant to support cross-data-type comparisons.
</para>
</listitem>
</varlistentry>