Oleg Bartunov <oleg@sai.msu.su> writes:
> On Thu, 17 May 2001, Tom Lane wrote:
>> We will also want to look at upgrading the non-btree index types to allow
>> concurrent operations.
> am I right you plan to work with GiST indexes as well ?
> We read a paper "Concurrency and Recovery in Generalized Search Trees"
> by Marcel Kornacker, C. Mohan, Joseph Hellerstein
> (http://citeseer.nj.nec.com/kornacker97concurrency.html)
> and probably we could go in this direction. Right now we're working
> on adding of multi-key support to GiST.
Yes, GIST should be upgraded to do concurrency. But I have no objection
if you want to work on multi-key support first.
My feeling is that a few releases from now we will have btree and GIST
as the preferred/well-supported index types. Hash and rtree might go
away altogether --- AFAICS they don't do anything that's not done as
well or better by btree or GIST, so what's the point of maintaining
them?
> btw, I have a question about function gistPageAddItem in gist.c
> it just decompress - compress key and calls PageAddItem to
> write tuple. We don't understand why do we need this function -
The comment says
** Take a compressed entry, and install it on a page. Since we now know
** where the entry will live, we decompress it and recompress it using
** that knowledge (some compression routines may want to fish around
** on the page, for example, or do something special for leaf nodes.)
Are you prepared to say that you will no longer support the ability for
GIST compression routines to do those things? That seems shortsighted.
regards, tom lane