Skip site navigation (1) Skip section navigation (2)

Re: GIN - Generalized Inverted iNdex. Try 3.

From: Teodor Sigaev <teodor(at)sigaev(dot)ru>
To: Christopher Kings-Lynne <chris(dot)kings-lynne(at)calorieking(dot)com>,Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: GIN - Generalized Inverted iNdex. Try 3.
Date: 2006-04-27 16:34:58
Message-ID: 4450F2B2.1050803@sigaev.ru (view raw or flat)
Thread:
Lists: pgsql-hackers
> I took the liberty of revising your README.txt as a native speaker :)  I 
>   cleaned up the grammar a lot, etc.

Thank you very much. I added your README to patch.

New version of GIN is available:

http://www.sigaev.ru/gin/gin.gz
http://www.sigaev.ru/gin/README.txt

Changes from Try 2:
* add regression tests for &&,@,~ operators
* add regression tests for GIN over int4[] and text[]
* fix regression opr_sanity test
* update README ( by Christopher )

Open Items:
   * Teach optimizer/executor that GIN is intrinsically clustered. i.e., it
     always returns ItemPointer in ascending order.
   * Tweak gincostestimate.
   * GIN stores several ItemPointer to heap tuple, so VACUUM FULL produces
     this warning message:
      WARNING:  index "idx" contains 88395 row versions, but table contains
                     51812 row versions
      HINT:  Rebuild the index with REINDEX.

We appreciate any comments, help and suggestions. For third item we haven't idea 
  how fix it except to exclude GIN index from check.

Sorry for our persistence, but we really need to known about choice of community 
about commiting or making contrib, because it will be difficult to support a big 
enough patch up to date...

-- 
Teodor Sigaev                                   E-mail: teodor(at)sigaev(dot)ru
                                                    WWW: http://www.sigaev.ru/

In response to

Responses

pgsql-hackers by date

Next:From: Greg StarkDate: 2006-04-27 16:43:37
Subject: Re: ANSI-strict pointer aliasing rules
Previous:From: Tom LaneDate: 2006-04-27 16:09:55
Subject: Re: pgsql: Change log message about vacuuming database name from LOG to

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group