diff options
author | Alexander Korotkov <akorotkov@postgresql.org> | 2020-03-30 19:17:11 +0300 |
---|---|---|
committer | Alexander Korotkov <akorotkov@postgresql.org> | 2020-03-30 19:17:23 +0300 |
commit | 911e70207703799605f5a0e8aad9f06cff067c63 (patch) | |
tree | 5cdbffea1945c2c0b766db195a55bcb372d60537 /src/include/access/gist.h | |
parent | 1d53432ff940b789c2431ba476a2a6e2db3edf84 (diff) | |
download | postgresql-911e70207703799605f5a0e8aad9f06cff067c63.tar.gz postgresql-911e70207703799605f5a0e8aad9f06cff067c63.zip |
Implement operator class parameters
PostgreSQL provides set of template index access methods, where opclasses have
much freedom in the semantics of indexing. These index AMs are GiST, GIN,
SP-GiST and BRIN. There opclasses define representation of keys, operations on
them and supported search strategies. So, it's natural that opclasses may be
faced some tradeoffs, which require user-side decision. This commit implements
opclass parameters allowing users to set some values, which tell opclass how to
index the particular dataset.
This commit doesn't introduce new storage in system catalog. Instead it uses
pg_attribute.attoptions, which is used for table column storage options but
unused for index attributes.
In order to evade changing signature of each opclass support function, we
implement unified way to pass options to opclass support functions. Options
are set to fn_expr as the constant bytea expression. It's possible due to the
fact that opclass support functions are executed outside of expressions, so
fn_expr is unused for them.
This commit comes with some examples of opclass options usage. We parametrize
signature length in GiST. That applies to multiple opclasses: tsvector_ops,
gist__intbig_ops, gist_ltree_ops, gist__ltree_ops, gist_trgm_ops and
gist_hstore_ops. Also we parametrize maximum number of integer ranges for
gist__int_ops. However, the main future usage of this feature is expected
to be json, where users would be able to specify which way to index particular
json parts.
Catversion is bumped.
Discussion: https://postgr.es/m/d22c3a18-31c7-1879-fc11-4c1ce2f5e5af%40postgrespro.ru
Author: Nikita Glukhov, revised by me
Reviwed-by: Nikolay Shaplov, Robert Haas, Tom Lane, Tomas Vondra, Alvaro Herrera
Diffstat (limited to 'src/include/access/gist.h')
-rw-r--r-- | src/include/access/gist.h | 22 |
1 files changed, 21 insertions, 1 deletions
diff --git a/src/include/access/gist.h b/src/include/access/gist.h index 73e43e880ab..4994351697c 100644 --- a/src/include/access/gist.h +++ b/src/include/access/gist.h @@ -16,6 +16,7 @@ #ifndef GIST_H #define GIST_H +#include "access/itup.h" #include "access/transam.h" #include "access/xlog.h" #include "access/xlogdefs.h" @@ -35,7 +36,8 @@ #define GIST_EQUAL_PROC 7 #define GIST_DISTANCE_PROC 8 #define GIST_FETCH_PROC 9 -#define GISTNProcs 9 +#define GIST_OPTIONS_PROC 10 +#define GISTNProcs 10 /* * Page opaque data in a GiST index page. @@ -74,6 +76,24 @@ typedef struct GISTPageOpaqueData typedef GISTPageOpaqueData *GISTPageOpaque; /* + * Maximum possible sizes for GiST index tuple and index key. Calculation is + * based on assumption that GiST page should fit at least 4 tuples. In theory, + * GiST index can be functional when page can fit 3 tuples. But that seems + * rather inefficent, so we use a bit conservative estimate. + * + * The maximum size of index key is true for unicolumn index. Therefore, this + * estimation should be used to figure out which maximum size of GiST index key + * makes sense at all. For multicolumn indexes, user might be able to tune + * key size using opclass parameters. + */ +#define GISTMaxIndexTupleSize \ + MAXALIGN_DOWN((BLCKSZ - SizeOfPageHeaderData - sizeof(GISTPageOpaqueData)) / \ + 4 - sizeof(ItemIdData)) + +#define GISTMaxIndexKeySize \ + (GISTMaxIndexTupleSize - MAXALIGN(sizeof(IndexTupleData))) + +/* * The page ID is for the convenience of pg_filedump and similar utilities, * which otherwise would have a hard time telling pages of different index * types apart. It should be the last 2 bytes on the page. This is more or |