![[Home]](/~megera/oddmuse/zen3.gif)
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.
