Re: GIST and TOAST
От | Teodor Sigaev |
---|---|
Тема | Re: GIST and TOAST |
Дата | |
Msg-id | 45ED9A4A.2090404@sigaev.ru обсуждение исходный текст |
Ответ на | Re: GIST and TOAST (Gregory Stark <stark@enterprisedb.com>) |
Ответы |
Re: GIST and TOAST
|
Список | 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 по дате отправления: