1996-08-28 03:59:28 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
1999-02-14 00:22:53 +01:00
|
|
|
* pg_opclass.h
|
1997-09-07 07:04:48 +02:00
|
|
|
* definition of the system "opclass" relation (pg_opclass)
|
|
|
|
* along with the relation's initial contents.
|
1996-08-28 03:59:28 +02:00
|
|
|
*
|
2006-12-23 01:43:13 +01:00
|
|
|
* The primary key for this table is <opcmethod, opcname, opcnamespace> ---
|
|
|
|
* that is, there is a row for each valid combination of opclass name and
|
|
|
|
* index access method type. This row specifies the expected input data type
|
|
|
|
* for the opclass (the type of the heap column, or the expression output type
|
|
|
|
* in the case of an index expression). Note that types binary-coercible to
|
|
|
|
* the specified type will be accepted too.
|
2001-08-21 18:36:06 +02:00
|
|
|
*
|
2006-12-23 01:43:13 +01:00
|
|
|
* For a given <opcmethod, opcintype> pair, there can be at most one row that
|
2001-08-21 18:36:06 +02:00
|
|
|
* has opcdefault = true; this row is the default opclass for such data in
|
2006-12-23 01:43:13 +01:00
|
|
|
* such an index. (This is not currently enforced by an index, because we
|
|
|
|
* don't support partial indexes on system catalogs.)
|
2001-08-21 18:36:06 +02:00
|
|
|
*
|
|
|
|
* Normally opckeytype = InvalidOid (zero), indicating that the data stored
|
2014-05-06 18:12:18 +02:00
|
|
|
* in the index is the same as the data in the indexed column. If opckeytype
|
2003-11-12 22:15:59 +01:00
|
|
|
* is nonzero then it indicates that a conversion step is needed to produce
|
|
|
|
* the stored index data, which will be of type opckeytype (which might be
|
2014-05-06 18:12:18 +02:00
|
|
|
* the same or different from the input datatype). Performing such a
|
2003-11-12 22:15:59 +01:00
|
|
|
* conversion is the responsibility of the index access method --- not all
|
|
|
|
* AMs support this.
|
2001-10-25 07:50:21 +02:00
|
|
|
*
|
1996-08-28 03:59:28 +02:00
|
|
|
*
|
2017-01-03 19:48:53 +01:00
|
|
|
* Portions Copyright (c) 1996-2017, PostgreSQL Global Development Group
|
2000-01-26 06:58:53 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
1996-08-28 03:59:28 +02:00
|
|
|
*
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/include/catalog/pg_opclass.h
|
1996-08-28 03:59:28 +02:00
|
|
|
*
|
|
|
|
* NOTES
|
2010-01-05 02:06:57 +01:00
|
|
|
* the genbki.pl script reads this file and generates .bki
|
1997-09-07 07:04:48 +02:00
|
|
|
* information from the DATA() statements.
|
1996-08-28 03:59:28 +02:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
#ifndef PG_OPCLASS_H
|
|
|
|
#define PG_OPCLASS_H
|
|
|
|
|
2008-03-27 04:57:34 +01:00
|
|
|
#include "catalog/genbki.h"
|
1996-08-28 03:59:28 +02:00
|
|
|
|
|
|
|
/* ----------------
|
2014-05-06 18:12:18 +02:00
|
|
|
* pg_opclass definition. cpp turns this into
|
1997-09-07 07:04:48 +02:00
|
|
|
* typedef struct FormData_pg_opclass
|
1996-08-28 03:59:28 +02:00
|
|
|
* ----------------
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
2005-04-14 03:38:22 +02:00
|
|
|
#define OperatorClassRelationId 2616
|
1996-08-28 03:59:28 +02:00
|
|
|
|
2005-04-14 03:38:22 +02:00
|
|
|
CATALOG(pg_opclass,2616)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2006-12-23 01:43:13 +01:00
|
|
|
Oid opcmethod; /* index access method opclass is for */
|
2001-08-21 18:36:06 +02:00
|
|
|
NameData opcname; /* name of this opclass */
|
2002-04-17 22:57:57 +02:00
|
|
|
Oid opcnamespace; /* namespace of this opclass */
|
2005-06-28 07:09:14 +02:00
|
|
|
Oid opcowner; /* opclass owner */
|
2006-12-23 01:43:13 +01:00
|
|
|
Oid opcfamily; /* containing operator family */
|
2003-11-12 22:15:59 +01:00
|
|
|
Oid opcintype; /* type of data indexed by opclass */
|
2001-08-21 18:36:06 +02:00
|
|
|
bool opcdefault; /* T if opclass is default for opcintype */
|
2003-11-12 22:15:59 +01:00
|
|
|
Oid opckeytype; /* type of data in index, or InvalidOid */
|
1996-08-28 03:59:28 +02:00
|
|
|
} FormData_pg_opclass;
|
|
|
|
|
|
|
|
/* ----------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* Form_pg_opclass corresponds to a pointer to a tuple with
|
|
|
|
* the format of pg_opclass relation.
|
1996-08-28 03:59:28 +02:00
|
|
|
* ----------------
|
|
|
|
*/
|
1997-09-07 07:04:48 +02:00
|
|
|
typedef FormData_pg_opclass *Form_pg_opclass;
|
1996-08-28 03:59:28 +02:00
|
|
|
|
|
|
|
/* ----------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* compiler constants for pg_opclass
|
1996-08-28 03:59:28 +02:00
|
|
|
* ----------------
|
|
|
|
*/
|
2006-12-23 01:43:13 +01:00
|
|
|
#define Natts_pg_opclass 8
|
|
|
|
#define Anum_pg_opclass_opcmethod 1
|
2001-08-21 18:36:06 +02:00
|
|
|
#define Anum_pg_opclass_opcname 2
|
2002-04-17 22:57:57 +02:00
|
|
|
#define Anum_pg_opclass_opcnamespace 3
|
|
|
|
#define Anum_pg_opclass_opcowner 4
|
2006-12-23 01:43:13 +01:00
|
|
|
#define Anum_pg_opclass_opcfamily 5
|
|
|
|
#define Anum_pg_opclass_opcintype 6
|
|
|
|
#define Anum_pg_opclass_opcdefault 7
|
|
|
|
#define Anum_pg_opclass_opckeytype 8
|
1996-08-28 03:59:28 +02:00
|
|
|
|
|
|
|
/* ----------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* initial contents of pg_opclass
|
2006-12-23 01:43:13 +01:00
|
|
|
*
|
|
|
|
* Note: we hard-wire an OID only for a few entries that have to be explicitly
|
2011-11-17 00:21:34 +01:00
|
|
|
* referenced in the C code or in built-in catalog entries. The rest get OIDs
|
2006-12-23 01:43:13 +01:00
|
|
|
* assigned on-the-fly during initdb.
|
1996-08-28 03:59:28 +02:00
|
|
|
* ----------------
|
|
|
|
*/
|
|
|
|
|
2006-12-23 01:43:13 +01:00
|
|
|
DATA(insert ( 403 abstime_ops PGNSP PGUID 421 702 t 0 ));
|
|
|
|
DATA(insert ( 403 array_ops PGNSP PGUID 397 2277 t 0 ));
|
2010-10-31 02:55:20 +01:00
|
|
|
DATA(insert ( 405 array_ops PGNSP PGUID 627 2277 t 0 ));
|
2006-12-23 01:43:13 +01:00
|
|
|
DATA(insert ( 403 bit_ops PGNSP PGUID 423 1560 t 0 ));
|
|
|
|
DATA(insert ( 403 bool_ops PGNSP PGUID 424 16 t 0 ));
|
|
|
|
DATA(insert ( 403 bpchar_ops PGNSP PGUID 426 1042 t 0 ));
|
|
|
|
DATA(insert ( 405 bpchar_ops PGNSP PGUID 427 1042 t 0 ));
|
|
|
|
DATA(insert ( 403 bytea_ops PGNSP PGUID 428 17 t 0 ));
|
|
|
|
DATA(insert ( 403 char_ops PGNSP PGUID 429 18 t 0 ));
|
|
|
|
DATA(insert ( 405 char_ops PGNSP PGUID 431 18 t 0 ));
|
|
|
|
DATA(insert ( 403 cidr_ops PGNSP PGUID 1974 869 f 0 ));
|
|
|
|
DATA(insert ( 405 cidr_ops PGNSP PGUID 1975 869 f 0 ));
|
2011-11-17 00:21:34 +01:00
|
|
|
DATA(insert OID = 3122 ( 403 date_ops PGNSP PGUID 434 1082 t 0 ));
|
|
|
|
#define DATE_BTREE_OPS_OID 3122
|
2006-12-23 01:43:13 +01:00
|
|
|
DATA(insert ( 405 date_ops PGNSP PGUID 435 1082 t 0 ));
|
|
|
|
DATA(insert ( 403 float4_ops PGNSP PGUID 1970 700 t 0 ));
|
|
|
|
DATA(insert ( 405 float4_ops PGNSP PGUID 1971 700 t 0 ));
|
2011-11-17 00:21:34 +01:00
|
|
|
DATA(insert OID = 3123 ( 403 float8_ops PGNSP PGUID 1970 701 t 0 ));
|
|
|
|
#define FLOAT8_BTREE_OPS_OID 3123
|
2006-12-23 01:43:13 +01:00
|
|
|
DATA(insert ( 405 float8_ops PGNSP PGUID 1971 701 t 0 ));
|
|
|
|
DATA(insert ( 403 inet_ops PGNSP PGUID 1974 869 t 0 ));
|
|
|
|
DATA(insert ( 405 inet_ops PGNSP PGUID 1975 869 t 0 ));
|
Add an in-core GiST index opclass for inet/cidr types.
This operator class can accelerate subnet/supernet tests as well as
btree-equivalent ordered comparisons. It also handles a new network
operator inet && inet (overlaps, a/k/a "is supernet or subnet of"),
which is expected to be useful in exclusion constraints.
Ideally this opclass would be the default for GiST with inet/cidr data,
but we can't mark it that way until we figure out how to do a more or
less graceful transition from the current situation, in which the
really-completely-bogus inet/cidr opclasses in contrib/btree_gist are
marked as default. Having the opclass in core and not default is better
than not having it at all, though.
While at it, add new documentation sections to allow us to officially
document GiST/GIN/SP-GiST opclasses, something there was never a clear
place to do before. I filled these in with some simple tables listing
the existing opclasses and the operators they support, but there's
certainly scope to put more information there.
Emre Hasegeli, reviewed by Andreas Karlsson, further hacking by me
2014-04-08 21:46:14 +02:00
|
|
|
DATA(insert ( 783 inet_ops PGNSP PGUID 3550 869 f 0 ));
|
2016-08-23 21:16:21 +02:00
|
|
|
DATA(insert ( 4000 inet_ops PGNSP PGUID 3794 869 t 0 ));
|
2006-12-23 01:43:13 +01:00
|
|
|
DATA(insert OID = 1979 ( 403 int2_ops PGNSP PGUID 1976 21 t 0 ));
|
|
|
|
#define INT2_BTREE_OPS_OID 1979
|
|
|
|
DATA(insert ( 405 int2_ops PGNSP PGUID 1977 21 t 0 ));
|
|
|
|
DATA(insert OID = 1978 ( 403 int4_ops PGNSP PGUID 1976 23 t 0 ));
|
2001-08-21 18:36:06 +02:00
|
|
|
#define INT4_BTREE_OPS_OID 1978
|
2006-12-23 01:43:13 +01:00
|
|
|
DATA(insert ( 405 int4_ops PGNSP PGUID 1977 23 t 0 ));
|
2011-11-17 00:21:34 +01:00
|
|
|
DATA(insert OID = 3124 ( 403 int8_ops PGNSP PGUID 1976 20 t 0 ));
|
|
|
|
#define INT8_BTREE_OPS_OID 3124
|
2006-12-23 01:43:13 +01:00
|
|
|
DATA(insert ( 405 int8_ops PGNSP PGUID 1977 20 t 0 ));
|
|
|
|
DATA(insert ( 403 interval_ops PGNSP PGUID 1982 1186 t 0 ));
|
|
|
|
DATA(insert ( 405 interval_ops PGNSP PGUID 1983 1186 t 0 ));
|
|
|
|
DATA(insert ( 403 macaddr_ops PGNSP PGUID 1984 829 t 0 ));
|
|
|
|
DATA(insert ( 405 macaddr_ops PGNSP PGUID 1985 829 t 0 ));
|
2017-03-15 16:16:25 +01:00
|
|
|
DATA(insert ( 403 macaddr8_ops PGNSP PGUID 3371 774 t 0 ));
|
|
|
|
DATA(insert ( 405 macaddr8_ops PGNSP PGUID 3372 774 t 0 ));
|
Reduce the alignment requirement of type "name" from int to char, and arrange
to suppress zero-padding of "name" entries in indexes.
The alignment change is unlikely to save any space, but it is really needed
anyway to make the world safe for our widespread practice of passing plain
old C strings to functions that are declared as taking Name. In the previous
coding, the C compiler was entitled to assume that a Name pointer was
word-aligned; but we were failing to guarantee that. I think the reason
we'd not seen failures is that usually the only thing that gets done with
such a pointer is strcmp(), which is hard to optimize in a way that exploits
word-alignment. Still, some enterprising compiler guy will probably think
of a way eventually, or we might change our code in a way that exposes
more-obvious optimization opportunities.
The padding change is accomplished in one-liner fashion by declaring the
"name" index opclasses to use storage type "cstring" in pg_opclass.h.
Normally btree and hash don't allow a nondefault storage type, because they
don't have any provisions for converting the input datum to another type.
However, because name and cstring are effectively the same thing except for
padding, no conversion is needed --- we only need index_form_tuple() to treat
the datum as being cstring not name, and this is sufficient. This seems to
make for about a one-third reduction in the typical sizes of system catalog
indexes that involve "name" columns, of which we have many.
These two changes are only weakly related, but the alignment change makes
me feel safer that the padding change won't introduce problems, so I'm
committing them together.
2008-06-24 19:58:27 +02:00
|
|
|
/*
|
|
|
|
* Here's an ugly little hack to save space in the system catalog indexes.
|
2008-09-15 20:43:41 +02:00
|
|
|
* btree doesn't ordinarily allow a storage type different from input type;
|
|
|
|
* but cstring and name are the same thing except for trailing padding,
|
Reduce the alignment requirement of type "name" from int to char, and arrange
to suppress zero-padding of "name" entries in indexes.
The alignment change is unlikely to save any space, but it is really needed
anyway to make the world safe for our widespread practice of passing plain
old C strings to functions that are declared as taking Name. In the previous
coding, the C compiler was entitled to assume that a Name pointer was
word-aligned; but we were failing to guarantee that. I think the reason
we'd not seen failures is that usually the only thing that gets done with
such a pointer is strcmp(), which is hard to optimize in a way that exploits
word-alignment. Still, some enterprising compiler guy will probably think
of a way eventually, or we might change our code in a way that exposes
more-obvious optimization opportunities.
The padding change is accomplished in one-liner fashion by declaring the
"name" index opclasses to use storage type "cstring" in pg_opclass.h.
Normally btree and hash don't allow a nondefault storage type, because they
don't have any provisions for converting the input datum to another type.
However, because name and cstring are effectively the same thing except for
padding, no conversion is needed --- we only need index_form_tuple() to treat
the datum as being cstring not name, and this is sufficient. This seems to
make for about a one-third reduction in the typical sizes of system catalog
indexes that involve "name" columns, of which we have many.
These two changes are only weakly related, but the alignment change makes
me feel safer that the padding change won't introduce problems, so I'm
committing them together.
2008-06-24 19:58:27 +02:00
|
|
|
* and we can safely omit that within an index entry. So we declare the
|
2008-09-15 20:43:41 +02:00
|
|
|
* btree opclass for name as using cstring storage type.
|
Reduce the alignment requirement of type "name" from int to char, and arrange
to suppress zero-padding of "name" entries in indexes.
The alignment change is unlikely to save any space, but it is really needed
anyway to make the world safe for our widespread practice of passing plain
old C strings to functions that are declared as taking Name. In the previous
coding, the C compiler was entitled to assume that a Name pointer was
word-aligned; but we were failing to guarantee that. I think the reason
we'd not seen failures is that usually the only thing that gets done with
such a pointer is strcmp(), which is hard to optimize in a way that exploits
word-alignment. Still, some enterprising compiler guy will probably think
of a way eventually, or we might change our code in a way that exposes
more-obvious optimization opportunities.
The padding change is accomplished in one-liner fashion by declaring the
"name" index opclasses to use storage type "cstring" in pg_opclass.h.
Normally btree and hash don't allow a nondefault storage type, because they
don't have any provisions for converting the input datum to another type.
However, because name and cstring are effectively the same thing except for
padding, no conversion is needed --- we only need index_form_tuple() to treat
the datum as being cstring not name, and this is sufficient. This seems to
make for about a one-third reduction in the typical sizes of system catalog
indexes that involve "name" columns, of which we have many.
These two changes are only weakly related, but the alignment change makes
me feel safer that the padding change won't introduce problems, so I'm
committing them together.
2008-06-24 19:58:27 +02:00
|
|
|
*/
|
|
|
|
DATA(insert ( 403 name_ops PGNSP PGUID 1986 19 t 2275 ));
|
2008-09-15 20:43:41 +02:00
|
|
|
DATA(insert ( 405 name_ops PGNSP PGUID 1987 19 t 0 ));
|
2012-06-10 21:20:04 +02:00
|
|
|
DATA(insert OID = 3125 ( 403 numeric_ops PGNSP PGUID 1988 1700 t 0 ));
|
2011-11-17 00:21:34 +01:00
|
|
|
#define NUMERIC_BTREE_OPS_OID 3125
|
2007-05-08 20:56:48 +02:00
|
|
|
DATA(insert ( 405 numeric_ops PGNSP PGUID 1998 1700 t 0 ));
|
2006-12-23 01:43:13 +01:00
|
|
|
DATA(insert OID = 1981 ( 403 oid_ops PGNSP PGUID 1989 26 t 0 ));
|
|
|
|
#define OID_BTREE_OPS_OID 1981
|
|
|
|
DATA(insert ( 405 oid_ops PGNSP PGUID 1990 26 t 0 ));
|
|
|
|
DATA(insert ( 403 oidvector_ops PGNSP PGUID 1991 30 t 0 ));
|
|
|
|
DATA(insert ( 405 oidvector_ops PGNSP PGUID 1992 30 t 0 ));
|
2008-10-13 18:25:20 +02:00
|
|
|
DATA(insert ( 403 record_ops PGNSP PGUID 2994 2249 t 0 ));
|
2013-10-09 21:26:09 +02:00
|
|
|
DATA(insert ( 403 record_image_ops PGNSP PGUID 3194 2249 f 0 ));
|
2011-11-17 00:21:34 +01:00
|
|
|
DATA(insert OID = 3126 ( 403 text_ops PGNSP PGUID 1994 25 t 0 ));
|
|
|
|
#define TEXT_BTREE_OPS_OID 3126
|
2006-12-23 01:43:13 +01:00
|
|
|
DATA(insert ( 405 text_ops PGNSP PGUID 1995 25 t 0 ));
|
|
|
|
DATA(insert ( 403 time_ops PGNSP PGUID 1996 1083 t 0 ));
|
|
|
|
DATA(insert ( 405 time_ops PGNSP PGUID 1997 1083 t 0 ));
|
2012-06-10 21:20:04 +02:00
|
|
|
DATA(insert OID = 3127 ( 403 timestamptz_ops PGNSP PGUID 434 1184 t 0 ));
|
2011-11-17 00:21:34 +01:00
|
|
|
#define TIMESTAMPTZ_BTREE_OPS_OID 3127
|
2007-11-15 22:14:46 +01:00
|
|
|
DATA(insert ( 405 timestamptz_ops PGNSP PGUID 1999 1184 t 0 ));
|
2006-12-23 01:43:13 +01:00
|
|
|
DATA(insert ( 403 timetz_ops PGNSP PGUID 2000 1266 t 0 ));
|
|
|
|
DATA(insert ( 405 timetz_ops PGNSP PGUID 2001 1266 t 0 ));
|
|
|
|
DATA(insert ( 403 varbit_ops PGNSP PGUID 2002 1562 t 0 ));
|
|
|
|
DATA(insert ( 403 varchar_ops PGNSP PGUID 1994 25 f 0 ));
|
|
|
|
DATA(insert ( 405 varchar_ops PGNSP PGUID 1995 25 f 0 ));
|
2011-11-17 00:21:34 +01:00
|
|
|
DATA(insert OID = 3128 ( 403 timestamp_ops PGNSP PGUID 434 1114 t 0 ));
|
|
|
|
#define TIMESTAMP_BTREE_OPS_OID 3128
|
2006-12-23 01:43:13 +01:00
|
|
|
DATA(insert ( 405 timestamp_ops PGNSP PGUID 2040 1114 t 0 ));
|
|
|
|
DATA(insert ( 403 text_pattern_ops PGNSP PGUID 2095 25 f 0 ));
|
|
|
|
DATA(insert ( 403 varchar_pattern_ops PGNSP PGUID 2095 25 f 0 ));
|
|
|
|
DATA(insert ( 403 bpchar_pattern_ops PGNSP PGUID 2097 1042 f 0 ));
|
|
|
|
DATA(insert ( 403 money_ops PGNSP PGUID 2099 790 t 0 ));
|
|
|
|
DATA(insert ( 405 bool_ops PGNSP PGUID 2222 16 t 0 ));
|
|
|
|
DATA(insert ( 405 bytea_ops PGNSP PGUID 2223 17 t 0 ));
|
|
|
|
DATA(insert ( 403 tid_ops PGNSP PGUID 2789 27 t 0 ));
|
|
|
|
DATA(insert ( 405 xid_ops PGNSP PGUID 2225 28 t 0 ));
|
|
|
|
DATA(insert ( 405 cid_ops PGNSP PGUID 2226 29 t 0 ));
|
|
|
|
DATA(insert ( 405 abstime_ops PGNSP PGUID 2227 702 t 0 ));
|
|
|
|
DATA(insert ( 405 reltime_ops PGNSP PGUID 2228 703 t 0 ));
|
|
|
|
DATA(insert ( 405 text_pattern_ops PGNSP PGUID 2229 25 f 0 ));
|
|
|
|
DATA(insert ( 405 varchar_pattern_ops PGNSP PGUID 2229 25 f 0 ));
|
|
|
|
DATA(insert ( 405 bpchar_pattern_ops PGNSP PGUID 2231 1042 f 0 ));
|
|
|
|
DATA(insert ( 403 reltime_ops PGNSP PGUID 2233 703 t 0 ));
|
|
|
|
DATA(insert ( 403 tinterval_ops PGNSP PGUID 2234 704 t 0 ));
|
|
|
|
DATA(insert ( 405 aclitem_ops PGNSP PGUID 2235 1033 t 0 ));
|
|
|
|
DATA(insert ( 783 box_ops PGNSP PGUID 2593 603 t 0 ));
|
2010-01-14 17:31:09 +01:00
|
|
|
DATA(insert ( 783 point_ops PGNSP PGUID 1029 600 t 603 ));
|
2006-12-23 01:43:13 +01:00
|
|
|
DATA(insert ( 783 poly_ops PGNSP PGUID 2594 604 t 603 ));
|
|
|
|
DATA(insert ( 783 circle_ops PGNSP PGUID 2595 718 t 603 ));
|
Replace the built-in GIN array opclasses with a single polymorphic opclass.
We had thirty different GIN array opclasses sharing the same operators and
support functions. That still didn't cover all the built-in types, nor
did it cover arrays of extension-added types. What we want is a single
polymorphic opclass for "anyarray". There were two missing features needed
to make this possible:
1. We have to be able to declare the index storage type as ANYELEMENT
when the opclass is declared to index ANYARRAY. This just takes a few
more lines in index_create(). Although this currently seems of use only
for GIN, there's no reason to make index_create() restrict it to that.
2. We have to be able to identify the proper GIN compare function for
the index storage type. This patch proceeds by making the compare function
optional in GIN opclass definitions, and specifying that the default btree
comparison function for the index storage type will be looked up when the
opclass omits it. Again, that seems pretty generically useful.
Since the comparison function lookup is done in initGinState(), making
use of the second feature adds an additional cache lookup to GIN index
access setup. It seems unlikely that that would be very noticeable given
the other costs involved, but maybe at some point we should consider
making GinState data persist longer than it now does --- we could keep it
in the index relcache entry, perhaps.
Rather fortuitously, we don't seem to need to do anything to get this
change to play nice with dump/reload or pg_upgrade scenarios: the new
opclass definition is automatically selected to replace existing index
definitions, and the on-disk data remains compatible. Also, if a user has
created a custom opclass definition for a non-builtin type, this doesn't
break that, since CREATE INDEX will prefer an exact match to opcintype
over a match to ANYARRAY. However, if there's anyone out there with
handwritten DDL that explicitly specifies _bool_ops or one of the other
replaced opclass names, they'll need to adjust that.
Tom Lane, reviewed by Enrique Meneses
Discussion: <14436.1470940379@sss.pgh.pa.us>
2016-09-26 20:52:44 +02:00
|
|
|
DATA(insert ( 2742 array_ops PGNSP PGUID 2745 2277 t 2283 ));
|
2007-04-02 05:49:42 +02:00
|
|
|
DATA(insert ( 403 uuid_ops PGNSP PGUID 2968 2950 t 0 ));
|
|
|
|
DATA(insert ( 405 uuid_ops PGNSP PGUID 2969 2950 t 0 ));
|
2014-06-05 02:45:56 +02:00
|
|
|
DATA(insert ( 403 pg_lsn_ops PGNSP PGUID 3253 3220 t 0 ));
|
|
|
|
DATA(insert ( 405 pg_lsn_ops PGNSP PGUID 3254 3220 t 0 ));
|
2007-04-02 05:49:42 +02:00
|
|
|
DATA(insert ( 403 enum_ops PGNSP PGUID 3522 3500 t 0 ));
|
|
|
|
DATA(insert ( 405 enum_ops PGNSP PGUID 3523 3500 t 0 ));
|
2007-08-21 03:11:32 +02:00
|
|
|
DATA(insert ( 403 tsvector_ops PGNSP PGUID 3626 3614 t 0 ));
|
|
|
|
DATA(insert ( 783 tsvector_ops PGNSP PGUID 3655 3614 t 3642 ));
|
|
|
|
DATA(insert ( 2742 tsvector_ops PGNSP PGUID 3659 3614 t 25 ));
|
|
|
|
DATA(insert ( 403 tsquery_ops PGNSP PGUID 3683 3615 t 0 ));
|
|
|
|
DATA(insert ( 783 tsquery_ops PGNSP PGUID 3702 3615 t 20 ));
|
2011-11-03 12:16:28 +01:00
|
|
|
DATA(insert ( 403 range_ops PGNSP PGUID 3901 3831 t 0 ));
|
|
|
|
DATA(insert ( 405 range_ops PGNSP PGUID 3903 3831 t 0 ));
|
|
|
|
DATA(insert ( 783 range_ops PGNSP PGUID 3919 3831 t 0 ));
|
2012-08-16 11:55:37 +02:00
|
|
|
DATA(insert ( 4000 range_ops PGNSP PGUID 3474 3831 t 0 ));
|
2016-06-10 00:02:36 +02:00
|
|
|
DATA(insert ( 4000 box_ops PGNSP PGUID 5000 603 t 0 ));
|
2011-12-17 22:41:16 +01:00
|
|
|
DATA(insert ( 4000 quad_point_ops PGNSP PGUID 4015 600 t 0 ));
|
|
|
|
DATA(insert ( 4000 kd_point_ops PGNSP PGUID 4016 600 f 0 ));
|
|
|
|
DATA(insert ( 4000 text_ops PGNSP PGUID 4017 25 t 0 ));
|
2017-12-25 16:59:38 +01:00
|
|
|
DATA(insert ( 4000 poly_ops PGNSP PGUID 5008 604 t 603 ));
|
Introduce jsonb, a structured format for storing json.
The new format accepts exactly the same data as the json type. However, it is
stored in a format that does not require reparsing the orgiginal text in order
to process it, making it much more suitable for indexing and other operations.
Insignificant whitespace is discarded, and the order of object keys is not
preserved. Neither are duplicate object keys kept - the later value for a given
key is the only one stored.
The new type has all the functions and operators that the json type has,
with the exception of the json generation functions (to_json, json_agg etc.)
and with identical semantics. In addition, there are operator classes for
hash and btree indexing, and two classes for GIN indexing, that have no
equivalent in the json type.
This feature grew out of previous work by Oleg Bartunov and Teodor Sigaev, which
was intended to provide similar facilities to a nested hstore type, but which
in the end proved to have some significant compatibility issues.
Authors: Oleg Bartunov, Teodor Sigaev, Peter Geoghegan and Andrew Dunstan.
Review: Andres Freund
2014-03-23 21:40:19 +01:00
|
|
|
DATA(insert ( 403 jsonb_ops PGNSP PGUID 4033 3802 t 0 ));
|
|
|
|
DATA(insert ( 405 jsonb_ops PGNSP PGUID 4034 3802 t 0 ));
|
|
|
|
DATA(insert ( 2742 jsonb_ops PGNSP PGUID 4036 3802 t 25 ));
|
2014-05-11 18:06:04 +02:00
|
|
|
DATA(insert ( 2742 jsonb_path_ops PGNSP PGUID 4037 3802 f 23 ));
|
2001-10-28 07:26:15 +01:00
|
|
|
|
BRIN: Block Range Indexes
BRIN is a new index access method intended to accelerate scans of very
large tables, without the maintenance overhead of btrees or other
traditional indexes. They work by maintaining "summary" data about
block ranges. Bitmap index scans work by reading each summary tuple and
comparing them with the query quals; all pages in the range are returned
in a lossy TID bitmap if the quals are consistent with the values in the
summary tuple, otherwise not. Normal index scans are not supported
because these indexes do not store TIDs.
As new tuples are added into the index, the summary information is
updated (if the block range in which the tuple is added is already
summarized) or not; in the latter case, a subsequent pass of VACUUM or
the brin_summarize_new_values() function will create the summary
information.
For data types with natural 1-D sort orders, the summary info consists
of the maximum and the minimum values of each indexed column within each
page range. This type of operator class we call "Minmax", and we
supply a bunch of them for most data types with B-tree opclasses.
Since the BRIN code is generalized, other approaches are possible for
things such as arrays, geometric types, ranges, etc; even for things
such as enum types we could do something different than minmax with
better results. In this commit I only include minmax.
Catalog version bumped due to new builtin catalog entries.
There's more that could be done here, but this is a good step forwards.
Loosely based on ideas from Simon Riggs; code mostly by Álvaro Herrera,
with contribution by Heikki Linnakangas.
Patch reviewed by: Amit Kapila, Heikki Linnakangas, Robert Haas.
Testing help from Jeff Janes, Erik Rijkers, Emanuel Calvo.
PS:
The research leading to these results has received funding from the
European Union's Seventh Framework Programme (FP7/2007-2013) under
grant agreement n° 318633.
2014-11-07 20:38:14 +01:00
|
|
|
/* BRIN operator classes */
|
|
|
|
/* no brin opclass for bool */
|
2015-05-24 03:35:49 +02:00
|
|
|
DATA(insert ( 3580 bytea_minmax_ops PGNSP PGUID 4064 17 t 17 ));
|
|
|
|
DATA(insert ( 3580 char_minmax_ops PGNSP PGUID 4062 18 t 18 ));
|
|
|
|
DATA(insert ( 3580 name_minmax_ops PGNSP PGUID 4065 19 t 19 ));
|
|
|
|
DATA(insert ( 3580 int8_minmax_ops PGNSP PGUID 4054 20 t 20 ));
|
|
|
|
DATA(insert ( 3580 int2_minmax_ops PGNSP PGUID 4054 21 t 21 ));
|
|
|
|
DATA(insert ( 3580 int4_minmax_ops PGNSP PGUID 4054 23 t 23 ));
|
|
|
|
DATA(insert ( 3580 text_minmax_ops PGNSP PGUID 4056 25 t 25 ));
|
|
|
|
DATA(insert ( 3580 oid_minmax_ops PGNSP PGUID 4068 26 t 26 ));
|
|
|
|
DATA(insert ( 3580 tid_minmax_ops PGNSP PGUID 4069 27 t 27 ));
|
2015-05-07 18:02:22 +02:00
|
|
|
DATA(insert ( 3580 float4_minmax_ops PGNSP PGUID 4070 700 t 700 ));
|
|
|
|
DATA(insert ( 3580 float8_minmax_ops PGNSP PGUID 4070 701 t 701 ));
|
|
|
|
DATA(insert ( 3580 abstime_minmax_ops PGNSP PGUID 4072 702 t 702 ));
|
|
|
|
DATA(insert ( 3580 reltime_minmax_ops PGNSP PGUID 4073 703 t 703 ));
|
|
|
|
DATA(insert ( 3580 macaddr_minmax_ops PGNSP PGUID 4074 829 t 829 ));
|
2017-03-15 16:16:25 +01:00
|
|
|
DATA(insert ( 3580 macaddr8_minmax_ops PGNSP PGUID 4109 774 t 774 ));
|
2015-05-07 18:02:22 +02:00
|
|
|
DATA(insert ( 3580 inet_minmax_ops PGNSP PGUID 4075 869 f 869 ));
|
2015-05-15 23:05:22 +02:00
|
|
|
DATA(insert ( 3580 inet_inclusion_ops PGNSP PGUID 4102 869 t 869 ));
|
2015-05-07 18:02:22 +02:00
|
|
|
DATA(insert ( 3580 bpchar_minmax_ops PGNSP PGUID 4076 1042 t 1042 ));
|
|
|
|
DATA(insert ( 3580 time_minmax_ops PGNSP PGUID 4077 1083 t 1083 ));
|
|
|
|
DATA(insert ( 3580 date_minmax_ops PGNSP PGUID 4059 1082 t 1082 ));
|
|
|
|
DATA(insert ( 3580 timestamp_minmax_ops PGNSP PGUID 4059 1114 t 1114 ));
|
|
|
|
DATA(insert ( 3580 timestamptz_minmax_ops PGNSP PGUID 4059 1184 t 1184 ));
|
|
|
|
DATA(insert ( 3580 interval_minmax_ops PGNSP PGUID 4078 1186 t 1186 ));
|
|
|
|
DATA(insert ( 3580 timetz_minmax_ops PGNSP PGUID 4058 1266 t 1266 ));
|
|
|
|
DATA(insert ( 3580 bit_minmax_ops PGNSP PGUID 4079 1560 t 1560 ));
|
|
|
|
DATA(insert ( 3580 varbit_minmax_ops PGNSP PGUID 4080 1562 t 1562 ));
|
|
|
|
DATA(insert ( 3580 numeric_minmax_ops PGNSP PGUID 4055 1700 t 1700 ));
|
BRIN: Block Range Indexes
BRIN is a new index access method intended to accelerate scans of very
large tables, without the maintenance overhead of btrees or other
traditional indexes. They work by maintaining "summary" data about
block ranges. Bitmap index scans work by reading each summary tuple and
comparing them with the query quals; all pages in the range are returned
in a lossy TID bitmap if the quals are consistent with the values in the
summary tuple, otherwise not. Normal index scans are not supported
because these indexes do not store TIDs.
As new tuples are added into the index, the summary information is
updated (if the block range in which the tuple is added is already
summarized) or not; in the latter case, a subsequent pass of VACUUM or
the brin_summarize_new_values() function will create the summary
information.
For data types with natural 1-D sort orders, the summary info consists
of the maximum and the minimum values of each indexed column within each
page range. This type of operator class we call "Minmax", and we
supply a bunch of them for most data types with B-tree opclasses.
Since the BRIN code is generalized, other approaches are possible for
things such as arrays, geometric types, ranges, etc; even for things
such as enum types we could do something different than minmax with
better results. In this commit I only include minmax.
Catalog version bumped due to new builtin catalog entries.
There's more that could be done here, but this is a good step forwards.
Loosely based on ideas from Simon Riggs; code mostly by Álvaro Herrera,
with contribution by Heikki Linnakangas.
Patch reviewed by: Amit Kapila, Heikki Linnakangas, Robert Haas.
Testing help from Jeff Janes, Erik Rijkers, Emanuel Calvo.
PS:
The research leading to these results has received funding from the
European Union's Seventh Framework Programme (FP7/2007-2013) under
grant agreement n° 318633.
2014-11-07 20:38:14 +01:00
|
|
|
/* no brin opclass for record, anyarray */
|
2015-05-07 18:02:22 +02:00
|
|
|
DATA(insert ( 3580 uuid_minmax_ops PGNSP PGUID 4081 2950 t 2950 ));
|
2015-05-15 23:05:22 +02:00
|
|
|
DATA(insert ( 3580 range_inclusion_ops PGNSP PGUID 4103 3831 t 3831 ));
|
2015-05-07 18:02:22 +02:00
|
|
|
DATA(insert ( 3580 pg_lsn_minmax_ops PGNSP PGUID 4082 3220 t 3220 ));
|
2015-05-15 23:05:22 +02:00
|
|
|
/* no brin opclass for enum, tsvector, tsquery, jsonb */
|
|
|
|
DATA(insert ( 3580 box_inclusion_ops PGNSP PGUID 4104 603 t 603 ));
|
|
|
|
/* no brin opclass for the geometric types except box */
|
BRIN: Block Range Indexes
BRIN is a new index access method intended to accelerate scans of very
large tables, without the maintenance overhead of btrees or other
traditional indexes. They work by maintaining "summary" data about
block ranges. Bitmap index scans work by reading each summary tuple and
comparing them with the query quals; all pages in the range are returned
in a lossy TID bitmap if the quals are consistent with the values in the
summary tuple, otherwise not. Normal index scans are not supported
because these indexes do not store TIDs.
As new tuples are added into the index, the summary information is
updated (if the block range in which the tuple is added is already
summarized) or not; in the latter case, a subsequent pass of VACUUM or
the brin_summarize_new_values() function will create the summary
information.
For data types with natural 1-D sort orders, the summary info consists
of the maximum and the minimum values of each indexed column within each
page range. This type of operator class we call "Minmax", and we
supply a bunch of them for most data types with B-tree opclasses.
Since the BRIN code is generalized, other approaches are possible for
things such as arrays, geometric types, ranges, etc; even for things
such as enum types we could do something different than minmax with
better results. In this commit I only include minmax.
Catalog version bumped due to new builtin catalog entries.
There's more that could be done here, but this is a good step forwards.
Loosely based on ideas from Simon Riggs; code mostly by Álvaro Herrera,
with contribution by Heikki Linnakangas.
Patch reviewed by: Amit Kapila, Heikki Linnakangas, Robert Haas.
Testing help from Jeff Janes, Erik Rijkers, Emanuel Calvo.
PS:
The research leading to these results has received funding from the
European Union's Seventh Framework Programme (FP7/2007-2013) under
grant agreement n° 318633.
2014-11-07 20:38:14 +01:00
|
|
|
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
#endif /* PG_OPCLASS_H */
|