On Sat, Jun 16, 2018 at 3:57 PM Darafei "Komяpa" Praliaskouski
<me@komzpa.net> wrote:
>>
>> > I'm not sure it is usefull in release notes since it is more about API, and not
>> > user-facing change. Just in case.
>> > GiST opclasses now can omit compress and decompress functions. If compress
>> > function is omited, IndexOnlyScan is enabled for opclass without any extra
>> > change.
>> > https://github.com/postgres/postgres/commit/
>> > d3a4f89d8a3e500bd7c0b7a8a8a5ce1b47859128
>>
>> Uh, we do have this for SP-GiST:
>>
>> Allow SP-GiST indexes to optionally use compression (Teodor Sigaev,
>> Heikki Linnakangas, Alexander Korotkov, Nikita Glukhov)
>>
>> I am unclear how far downt the API stack I should go in documenting
>> changes like this.
>
>
> It is also a bit misleading - the idea in that change is that now index representation can be a lossy version of
actualdata type (a box instead of polygon as a referende, so a changelog entry can tell "Allow SP-GiST index creation
forpolygon datatype."). There is no "decompression" for such thing. "compression" sounds like gzip for me in
user-facingcontext.
+1 that current wording looks confusing. But I think we need to
highlight that we have general SP-GiST improvement, not just support
for particular datatype. So, I propose following wording: "Allow
SP-GiST to use lossy representation of leaf keys, and add SP-GiST
support for polygon type using that".
I would also like to highlight, that there is a set of typos found my
Liudmila Mantrova in documentation including release notes [1]. As
you know, I'm not native English speaker, but fixes proposed by
Liudmila looks correct for me.
1. https://www.postgresql.org/message-id/275fc450-bbc9-a715-04bb-3b7104fecfcd%40postgrespro.ru
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company