Re: Cube extension point support // GSoC'13
От | Alexander Korotkov |
---|---|
Тема | Re: Cube extension point support // GSoC'13 |
Дата | |
Msg-id | CAPpHfdsSv_+YR_EsoNnKfy77fboJgoGqS3N3c5jFujVu-fo8Gg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Cube extension point support // GSoC'13 (Dimitri Fontaine <dimitri@2ndQuadrant.fr>) |
Список | pgsql-hackers |
On Tue, Oct 22, 2013 at 2:00 AM, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
------
With best regards,
Alexander Korotkov.
Tom Lane <tgl@sss.pgh.pa.us> writes:My understanding of the use case for those functions is to do with
> 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.
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.
Actually, I mean purpose of this particular decompress function implementation, not compress/decompress in general. I understand that in general compress/decompress can do useful job.
------
With best regards,
Alexander Korotkov.
В списке pgsql-hackers по дате отправления: