Re: [HACKERS] Cube extension point support // GSoC'13 - Mailing list pgsql-students

From Dimitri Fontaine
Subject Re: [HACKERS] Cube extension point support // GSoC'13
Date
Msg-id m28uxmthc7.fsf@2ndQuadrant.fr
Whole thread Raw
In response to Re: [HACKERS] Cube extension point support // GSoC'13  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Cube extension point support // GSoC'13
List pgsql-students
Tom Lane <tgl@sss.pgh.pa.us> writes:
> I believe the reason GIST has compress/decompress functions is not for
> TOAST (they predate that, if memory serves), but to allow the on-disk
> representation of an index entry to be different from the data type's
> normal representation in other ways --- think lossy storage in particular.

My understanding of the use case for those functions is to do with
storing a different data type in the index upper nodes and in the index
leafs. It should be possible to do that in a non-lossy way, so that you
would implement compress/decompress and not declare the RECHECK bits.

Then again I'm talking from 8.3 era memories of when I tried to
understand GiST enough to code the prefix extension.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support


pgsql-students by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Cube extension point support // GSoC'13
Next
From: Alexander Korotkov
Date:
Subject: Re: [HACKERS] Cube extension point support // GSoC'13