Re: Cube extension point support // GSoC'13

On Fri, Oct 11, 2013 at 5:56 PM, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com
> wrote:

> 2. I didn't understand this change:
>
> @@ -422,24 +439,14 @@ g_cube_union(PG_FUNCTION_ARGS)
>> Datum
>> g_cube_compress(PG_FUNCTION_**ARGS)
>> {
>> - PG_RETURN_DATUM(PG_GETARG_**DATUM(0));
>> + GISTENTRY *entry = (GISTENTRY *) PG_GETARG_POINTER(0);
>> + PG_RETURN_POINTER(entry);
>> }
>>
>> Datum
>> g_cube_decompress(PG_FUNCTION_**ARGS)
>> {
>> GISTENTRY *entry = (GISTENTRY *) PG_GETARG_POINTER(0);
>> - NDBOX *key = DatumGetNDBOX(PG_DETOAST_**DATUM(entry->key));
>> -
>> - if (key != DatumGetNDBOX(entry->key))
>> - {
>> - GISTENTRY *retval = (GISTENTRY *)
>> palloc(sizeof(GISTENTRY));
>> -
>> - gistentryinit(*retval, PointerGetDatum(key),
>> - entry->rel, entry->page,
>> - entry->offset, FALSE);
>> - PG_RETURN_POINTER(retval);
>> - }
>> PG_RETURN_POINTER(entry);
>> }
>>
>>
> What did the removed code do, and why isn't it needed anymore?

I don't understand this place even more generally. What decompress function
do is to detoast key and return new gist entry with it if needed. But can
GiST key ever be toasted? My experiments show that answer is no, it can't.
When too long key is passed then GiST falls during inserting key into page.
And I didn't find any code doing GiST key toast in git.
However taking care about key toast is sequentially repeated in GiST
related code. For example, in contrib/intarray/_int.h

#define SIGLENINT 63 /* >122 => key will *toast*, so very slow!!! */

Any ideas?

------
With best regards,
Alexander Korotkov.