Re: GIST and TOAST - Mailing list pgsql-hackers

From Teodor Sigaev
Subject Re: GIST and TOAST
Date
Msg-id 45ED9A4A.2090404@sigaev.ru
Whole thread Raw
In response to Re: GIST and TOAST  (Gregory Stark <stark@enterprisedb.com>)
Responses Re: GIST and TOAST  (Gregory Stark <stark@enterprisedb.com>)
List pgsql-hackers
> So when does index_form_tuple get called?

The single call of index_form_tuple in GiST core is in gistFormTuple which 
initially compress any indexed value with a help of their compress methods.

Only tuples formed by gistFormTuple could be inserted in index.

> Does every data type define a compress/decompress method? Even if it's not a
> data type that normally gets very large?

Yes, any GiST opclass should have such methods. In trivial case it just returns  input value. As I remember, only
R-Treeemulation over boxes, contrib/seg and 
 
contrib/cube have simple compress method.


> Well we cheated a bit and had heap/index_form_tuple convert the data to packed
> format. This saves having to push small tuples through the toaster. So now
> tuples can magically become toasted as soon as they go into a tuple even if
> they never get pushed through the toaster. 
Ok, it should be safe for GiST except some possible memory management issue. 
index_form_tuple in GiST works in GiST's memory context which is short-live. Is 
it possible issue for your patch? BTW, that's connected to GIN too.


> So it's perfectly safe to just use DatumGetType and PG_GETARG_TYPE instead of
> using DatumGetPointer and PG_GETARG_POINTER and having to manually cast
> everywhere, no? It seems like there's a lot of extra pain to maintain the code
> in the present style with all the manual casts.
Of course, I agree. Just PG_FREE_IF_COPY is extra call in support methods.

-- 
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
  WWW: http://www.sigaev.ru/
 


pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: Synchronized Scan update
Next
From: Teodor Sigaev
Date:
Subject: Re: GIST and TOAST