Date: Mon, 18 Dec 2017 11:54:31 +0300
From: Ildus Kurbangaliev <i.kurbangaliev@postgrespro.ru>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Alexander Korotkov <a.korotkov@postgrespro.ru>, Tomas Vondra
 <tomas.vondra@2ndquadrant.com>, Alvaro Herrera <alvherre@2ndquadrant.com>,
 =?UTF-8?B?0JXQstCz0LXQvdC40Lkg0KjQuNGI0LrQuNC9?= <itparanoia@gmail.com>,
 Andres Freund <andres@anarazel.de>, Oleg Bartunov <obartunov@gmail.com>,
 Craig Ringer <craig@2ndquadrant.com>, Peter Eisentraut
 <peter.eisentraut@2ndquadrant.com>, PostgreSQL Hackers
 <pgsql-hackers@postgresql.org>, Chapman Flack <chap@anastigmatix.net>
Subject: Re: [HACKERS] Custom compression methods
Message-ID: <20171218115431.2b3e29ba@wp.localdomain>
In-Reply-To: 
 <CA+TgmoZ68LyL0rFPDgC1J-6p9ZQZc2xS4Txd-9661s+w6_MwBg@mail.gmail.com>
References: <20171201194859.le5hvnnrjzhxhm2t@alvherre.pgsql>
	<bc4e4595-24c5-c2eb-323e-9f31e9c98140@2ndquadrant.com>
	<20171206180716.75ba9ba9@postgrespro.ru>
	<CA+TgmobjDLp5xxodzN+TwhuhdQxM3wJw6AaLatDaBgPQm+N+kw@mail.gmail.com>
	<20171211155555.05ddd2fc@postgrespro.ru>
	<CA+Tgmoa7U9Pgc8YV-eRkKAK2s74aL6Yw1Wsj81PTjyrn0Eg99g@mail.gmail.com>
	<CAPpHfdsO0wSy6ZEoOQS5AkxTRXeCzv4uz=S8hOOJNgOxPmJW4A@mail.gmail.com>
	<CA+TgmoYqG2DFHDEM9ixMQA0p9d=_w6pYaa-+Jue4PP56VNSCWQ@mail.gmail.com>
	<CAPpHfduP77qxdETcPRc_FGOVJpeSCwNGoSUgNU3BCHXu57RVMA@mail.gmail.com>
	<CA+TgmoZqJYP+othk0c-r6acjVWWvBoxkWm5eHLUE=8VyezQKKw@mail.gmail.com>
	<20171213151818.75a20259@postgrespro.ru>
	<CA+TgmoZ68LyL0rFPDgC1J-6p9ZQZc2xS4Txd-9661s+w6_MwBg@mail.gmail.com>
Organization: Postgres Professional
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Thu, 14 Dec 2017 10:29:10 -0500
Robert Haas <robertmhaas@gmail.com> wrote:

> On Wed, Dec 13, 2017 at 7:18 AM, Ildus Kurbangaliev
> <i.kurbangaliev@postgrespro.ru> wrote:
> > Since we agreed on ALTER syntax, i want to clear things about
> > CREATE. Should it be CREATE ACCESS METHOD .. TYPE =D0=A1OMPRESSION or
> > CREATE COMPRESSION METHOD? I like the access method approach, and it
> > simplifies the code, but I'm just not sure a compression is an
> > access method or not. =20
>=20
> +1 for ACCESS METHOD.

An access method then.

>=20
> > Current implementation
> > ----------------------
> >
> > To avoid extra patches I also want to clear things about current
> > implementation. Right now there are two tables, "pg_compression" and
> > "pg_compression_opt". When compression method is linked to a column
> > it creates a record in pg_compression_opt. This record's Oid is
> > stored in the varlena. These Oids kept in first column so I can
> > move them in pg_upgrade but in all other aspects they behave like
> > usual Oids. Also it's easy to restore them. =20
>=20
> pg_compression_opt -> pg_attr_compression, maybe.
>=20
> > Compression options linked to a specific column. When tuple is
> > moved between relations it will be decompressed. =20
>=20
> Can we do this only if the compression method isn't OK for the new
> column?  For example, if the old column is COMPRESS foo PRESERVE bar
> and the new column is COMPRESS bar PRESERVE foo, we don't need to
> force decompression in any case.

Thanks, sounds right, i will add it to the patch.

--=20
---
Ildus Kurbangaliev
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company