Re: Allow GiST opcalsses without compress\decompres functions

From: Andrew Borodin <borodin(at)octonica(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Borodin <amborodin(at)acm(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Allow GiST opcalsses without compress\decompres functions
Date: 2017-05-28 18:51:16
Message-ID: CAJEAwVF37=btrRiNka58W=8W2JLLa4Neok27=E6xSUW-TsRcqw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

28 мая 2017 г. 11:15 PM пользователь "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> написал:

Andrew Borodin <borodin(at)octonica(dot)com> writes:
> 2017-05-28 22:22 GMT+05:00 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>> 2. If compress/decompress are omitted, then we could support index-only
>> scans all the time, that is a no-op fetch function would work. The
>> patch should cover that interaction too.

> I do not think so. Decompress have to get att to the state where
> consistency function can understand it. In theory. I've checked like a
> dozen of types and have not found places where fetch should differ
> from decompress.

But if compress is omitted, then we know the in-index representation
is the same as the original. Therefore the fetch function would always
be a no-op and we can implement IOS whether or not the opclass designer
bothered to supply one.

regards, tom lane

True. If there is no code to "hash" original value, it is not hashed, it's
whole...

I'm not expert in toasting, cube's compress does nothing while cube
decomress does detoasting. Is this for reason?

Best regards, Andrey Borodin.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-05-28 19:00:47 Re: Allow GiST opcalsses without compress\decompres functions
Previous Message Alvaro Herrera 2017-05-28 18:39:03 Re: pg_upgrade translation