Re: GIST and TOAST - Mailing list pgsql-hackers

From Teodor Sigaev
Subject Re: GIST and TOAST
Date
Msg-id 45EDA079.4060707@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
>> 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 by date:

Previous
From: Chris Browne
Date:
Subject: Re: Auto creation of Partitions
Next
From: Tom Lane
Date:
Subject: Plan invalidation vs. unnamed prepared statements