From: Ildus Kurbangaliev <i.kurbangaliev@postgrespro.ru>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Alexander Korotkov <a.korotkov@postgrespro.ru>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Евгений Шишкин <itparanoia@gmail.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: Oleg Bartunov <obartunov@gmail.com>
Cc: Craig Ringer <craig@2ndquadrant.com>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Cc: Chapman Flack <chap@anastigmatix.net>
Subject: Re: [HACKERS] Custom compression methods
Date: Mon, 18 Dec 2017 11:54:31 +0300
Message-ID: <20171218115431.2b3e29ba@wp.localdomain> (raw)
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>
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 СOMPRESSION 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.
>
> +1 for ACCESS METHOD.
An access method then.
>
> > 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.
>
> pg_compression_opt -> pg_attr_compression, maybe.
>
> > Compression options linked to a specific column. When tuple is
> > moved between relations it will be decompressed.
>
> 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.
--
---
Ildus Kurbangaliev
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: i.kurbangaliev@postgrespro.ru, robertmhaas@gmail.com, a.korotkov@postgrespro.ru, tomas.vondra@2ndquadrant.com, alvherre@2ndquadrant.com, itparanoia@gmail.com, andres@anarazel.de, obartunov@gmail.com, craig@2ndquadrant.com, peter.eisentraut@2ndquadrant.com, chap@anastigmatix.net
Subject: Re: [HACKERS] Custom compression methods
In-Reply-To: <20171218115431.2b3e29ba@wp.localdomain>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox