On Sat, Jun 16, 2018 at 3:57 PM Darafei "Komяpa" Praliaskouski <m...@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 actual data type (a box instead of > polygon as a referende, so a changelog entry can tell "Allow SP-GiST index > creation for polygon datatype."). There is no "decompression" for such > thing. "compression" sounds like gzip for me in user-facing context.
+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
