On Tue, Jun 19, 2018 at 12:15 PM Alexander Korotkov <a.korot...@postgrespro.ru> wrote: > 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".
Oh, I missed that we have separate release notes entry for polygons indexing. Then second part of sentence isn't needed, it should be just "Allow SP-GiST to use lossy representation of leaf keys". If no objections, I'm going to commit that altogether with fixes by Liudmila. ------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
spgist-compress-release-notes.patch
Description: Binary data
