Re: GIST and TOAST
От | Teodor Sigaev |
---|---|
Тема | Re: GIST and TOAST |
Дата | |
Msg-id | 45EDA079.4060707@sigaev.ru обсуждение исходный текст |
Ответ на | Re: GIST and TOAST (Gregory Stark <stark@enterprisedb.com>) |
Ответы |
Re: GIST and TOAST
|
Список | pgsql-hackers |
>> input value. As I remember, only R-Tree emulation over boxes, contrib/seg and >> contrib/cube have simple compress method. > Hm, if they just return the original datum without detoasting it then it could > be an issue. I'll check. seg and box aren't a varlena types, but cube is and it seems broken :(. g_cube_decompress and g_cube_compress don't detoast values. I'll fix that. > index_form_tuple doesn't leak memory. packed varlena format just has a shorter > header so it can store the header and then copy the data to the new location. > It doesn't have to create a copy of the data (except in the tuple, obviously). Nice, now that's clear. > But it means index_getattr can return a toasted tuple. I see several calls to > index_getattr that immediately put the datum into a GISTENTRY and call support > functions like the union function. For example gistMakeUnionItVec does this.From gistMakeUnionItVec: datum = index_getattr(itvec[j], i + 1, giststate->tupdesc, &IsNull); if (IsNull) continue; gistdentryinit(giststate, i, evec->vector + evec->n, datum, ) gistdentryinit calls user-defined decompress method. The reason of confusion is: there is three similar functions/macros: gistentryinit, gistcentryinit and gistdentryinit :) That names was choosen by authors initially developed GiST in pgsql. > Well if you're doing everything in short-lived memory contexts then we don't > even need this. Sure -- Teodor Sigaev E-mail: teodor@sigaev.ru WWW: http://www.sigaev.ru/
В списке pgsql-hackers по дате отправления: