pgsql: Replace the built-in GIN array opclasses with a single polymorph - Mailing list pgsql-committers

From Tom Lane
Subject pgsql: Replace the built-in GIN array opclasses with a single polymorph
Date
Msg-id E1bob1J-0003Xq-8Y@gemulon.postgresql.org
Whole thread Raw
List pgsql-committers
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>

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/fdc9186f7ed1ead827509584f3b763f8dc332c43

Modified Files
--------------
doc/src/sgml/gin.sgml                | 349 ++++-------------------------------
doc/src/sgml/indices.sgml            |   5 +-
doc/src/sgml/ref/create_opclass.sgml |   5 +
doc/src/sgml/xindex.sgml             |   2 +-
src/backend/access/gin/ginutil.c     |  32 +++-
src/backend/access/gin/ginvalidate.c |   2 +-
src/backend/catalog/index.c          |  19 +-
src/include/catalog/catversion.h     |   2 +-
src/include/catalog/pg_amop.h        |   3 +-
src/include/catalog/pg_amproc.h      | 154 +---------------
src/include/catalog/pg_opclass.h     |  31 +---
11 files changed, 101 insertions(+), 503 deletions(-)


pgsql-committers by date:

Previous
From: Peter Eisentraut
Date:
Subject: pgsql: Translation updates
Next
From: Tom Lane
Date:
Subject: Re: pgsql: Refactor script execution state machine in pgbench.