Re: compress method for spgist - 2 - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: compress method for spgist - 2
Date
Msg-id 54993A76.7050308@vmware.com
Whole thread Raw
In response to Re: compress method for spgist - 2  (Teodor Sigaev <teodor@sigaev.ru>)
Responses Re: compress method for spgist - 2  (Teodor Sigaev <teodor@sigaev.ru>)
Re: compress method for spgist - 2  (Teodor Sigaev <teodor@sigaev.ru>)
List pgsql-hackers
On 12/16/2014 07:48 PM, Teodor Sigaev wrote:
> /*
>  * This struct is what we actually keep in index->rd_amcache.  It includes
>  * static configuration information as well as the lastUsedPages cache.
>  */
> typedef struct SpGistCache
> {
>         spgConfigOut config;            /* filled in by opclass config method */
>
>         SpGistTypeDesc attType;         /* type of input data and leaf values */
>         SpGistTypeDesc attPrefixType;           /* type of inner-tuple prefix values */
>         SpGistTypeDesc attLabelType;    /* type of node label values */
>
>         SpGistLUPCache lastUsedPages;           /* local storage of last-used info */
> } SpGistCache;

Now that the input data type and leaf data type can be different, which
one is "attType"? It's the leaf data type, as the patch stands. I
renamed that to attLeafType, and went fixing all the references to it.
In most places it's just a matter of search & replace, but what about
the reconstructed datum? In freeScanStackEntry, we assume that
att[Leaf]Type is the datatype for reconstructedValue, but I believe
assume elsewhere that reconstructedValue is of the same data type as the
input. At least if the opclass supports index-only scans.

I think we'll need a separate SpGistTypeDesc for the input type. Or
perhaps a separate SpGistTypeDesc for the reconstructed value and an
optional decompress method to turn the reconstructedValue back into an
actual reconstructed input datum. Or something like that.

Attached is a patch with the kibitzing I did so far.

- Heikki


Attachment

pgsql-hackers by date:

Previous
From: Atri Sharma
Date:
Subject: Re: mysql with postgres
Next
From: Heikki Linnakangas
Date:
Subject: Re: PATCH: adaptive ndistinct estimator v3 (WAS: Re: [PERFORM] Yet another abort-early plan disaster on 9.3)