pgsql: Fix GIN to support null keys, empty and null items, and full ind

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql: Fix GIN to support null keys, empty and null items, and full ind
Date: 2011-01-08 00:17:34
Message-ID: E1PbMUw-00075e-Qu@gemulon.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Fix GIN to support null keys, empty and null items, and full index scans.

Per my recent proposal(s). Null key datums can now be returned by
extractValue and extractQuery functions, and will be stored in the index.
Also, placeholder entries are made for indexable items that are NULL or
contain no keys according to extractValue. This means that the index is
now always complete, having at least one entry for every indexed heap TID,
and so we can get rid of the prohibition on full-index scans. A full-index
scan is implemented much the same way as partial-match scans were already:
we build a bitmap representing all the TIDs found in the index, and then
drive the results off that.

Also, introduce a concept of a "search mode" that can be requested by
extractQuery when the operator requires matching to empty items (this is
just as cheap as matching to a single key) or requires a full index scan
(which is not so cheap, but it sure beats failing or giving wrong answers).
The behavior remains backward compatible for opclasses that don't return
any null keys or request a non-default search mode.

Using these features, we can now make the GIN index opclass for anyarray
behave in a way that matches the actual anyarray operators for &&, <@, @>,
and = ... which it failed to do before in assorted corner cases.

This commit fixes the core GIN code and ginarrayprocs.c, updates the
documentation, and adds some simple regression test cases for the new
behaviors using the array operators. The tsearch and contrib GIN opclass
support functions still need to be looked over and probably fixed.

Another thing I intend to fix separately is that this is pretty inefficient
for cases where more than one scan condition needs a full-index search:
we'll run duplicate GinScanEntrys, each one of which builds a large bitmap.
There is some existing logic to merge duplicate GinScanEntrys but it needs
refactoring to make it work for entries belonging to different scan keys.

Note that most of gin.h has been split out into a new file gin_private.h,
so that gin.h doesn't export anything that's not supposed to be used by GIN
opclasses or the rest of the backend. I did quite a bit of other code
beautification work as well, mostly fixing comments and choosing more
appropriate names for things.

Branch
------
master

Details
-------
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=73912e7fbd1b52c51d914214abbec1cda64595f2

Modified Files
--------------
contrib/hstore/hstore_gin.c | 1 +
doc/src/sgml/gin.sgml | 262 ++++++---
src/backend/access/gin/README | 180 +++++-
src/backend/access/gin/ginarrayproc.c | 168 ++++--
src/backend/access/gin/ginbtree.c | 6 +-
src/backend/access/gin/ginbulk.c | 134 +++--
src/backend/access/gin/gindatapage.c | 53 ++-
src/backend/access/gin/ginentrypage.c | 329 ++++++-----
src/backend/access/gin/ginfast.c | 181 ++++---
src/backend/access/gin/ginget.c | 858 ++++++++++++++++------------
src/backend/access/gin/gininsert.c | 266 ++++++---
src/backend/access/gin/ginscan.c | 283 +++++++---
src/backend/access/gin/ginutil.c | 293 +++++++---
src/backend/access/gin/ginvacuum.c | 21 +-
src/backend/access/gin/ginxlog.c | 21 +-
src/include/access/gin.h | 612 +-------------------
src/include/access/gin_private.h | 710 +++++++++++++++++++++++
src/include/utils/builtins.h | 5 +
src/test/regress/data/array.data | 3 +
src/test/regress/expected/arrays.out | 276 +++++++++-
src/test/regress/expected/create_index.out | 438 ++++++++++-----
src/test/regress/sql/arrays.sql | 12 +
src/test/regress/sql/create_index.sql | 54 +-
23 files changed, 3311 insertions(+), 1855 deletions(-)

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2011-01-08 01:41:33 pgsql: Fix the built-in GIN support procedure declarations in pg_proc.h
Previous Message Chris Browne 2011-01-07 17:37:35 Re: [COMMITTERS] pgsql: Implement remaining fields of information_schema.sequences view