2009-03-24

GIN fastupdate committed !

Tom Lane just committed GIN fastupdate patch to the CVS HEAD. We spent about 30 versions of the patch since last PGCon 2008 ! The basic idea was described in commit log:

Log Message:
-----------
Implement "fastupdate" support for GIN indexes, in which we try to
accumulate
multiple index entries in a holding area before adding them to the main
index
structure.  This helps because bulk insert is (usually) significantly faster
than retail insert for GIN.

This patch also removes GIN support for amgettuple-style index scans.  The
API defined for amgettuple is difficult to support with fastupdate, and
the previously committed partial-match feature didn't really work with
it either.  We might eventually figure a way to put back amgettuple
support, but it won't happen for 8.4.

catversion bumped because of change in GIN's pg_am entry, and because
the format of GIN indexes changed on-disk (there's a metapage now,
and possibly a pending list).

Teodor Sigaev

Tom removed pending list cleanup during vacuum analyze command, which now occurs only during "auto-ANALYZE".

Also, GIN got defense from degradation when the input data are sorted or so, which case the tree unbalanced and the insertion speed become O(N^2). We hope in future release to implement rebalancing tree algorithm, Teodor's idea

> Yes, this is probably the same issue I bumped into a while ago:
> 
> http://archives.postgresql.org/message-id/49350A13.3020105@enterprisedb.co
> m
Exactly. I'm working on red-black tree to solve that, but for next release
because of feature freeze.I'd like to implement some generic tree because it
will be useful in several parts of postgres:
- GIN
- Bentley-Ottomann algorithm for intersection and containment of polygons.
Currently, intersection of polygons checks only bounding boxes, contains
algorithm doesn't work correctly for complex (and even just concave)
polygons.

Now I did implementation of red-black tree although it's not well tested.