Re: compress method for spgist - 2

From: Teodor Sigaev <teodor(at)sigaev(dot)ru>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: compress method for spgist - 2
Date: 2014-12-23 13:02:22
Message-ID: 549967DE.1030103@sigaev.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> 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.

Agree with rename. I doubt that there is a real-world example of datatype which
can be a) effectivly compressed and b) restored to original form. If so, why
don't store it in compressed state in database? In GiST all compress methods
uses one-way compress. In PostGIS example, polygons are "compressed" into
bounding box, and, obviously, they cannot be restored.

>
> 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.

I suppose that compress and reconstruct are mutual exclusive options.

--
Teodor Sigaev E-mail: teodor(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2014-12-23 13:22:48 pgsql: Use a bitmask to represent role attributes
Previous Message Tomas Vondra 2014-12-23 12:25:33 Re: 9.5: Better memory accounting, towards memory-bounded HashAgg