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: Wed, 13 Dec 2017 15:18:18 +0300
Message-ID: <20171213151818.75a20259@postgrespro.ru> (raw)
In-Reply-To: <CA+TgmoZqJYP+othk0c-r6acjVWWvBoxkWm5eHLUE=8VyezQKKw@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>
On Tue, 12 Dec 2017 15:52:01 -0500
Robert Haas <robertmhaas@gmail.com> wrote:
>
> Yes. I wonder if \d or \d+ can show it somehow.
>
Yes, in current version of the patch, \d+ shows current compression.
It can be extended to show a list of current compression methods.
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.
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.
Compression options linked to a specific column. When tuple is
moved between relations it will be decompressed.
Also in current implementation SET COMPRESSION contains WITH syntax
which is used to provide extra options to compression method.
What could be changed
---------------------
As Alvaro mentioned COMPRESSION METHOD is practically an access method,
so it could be created as CREATE ACCESS METHOD .. TYPE COMPRESSION.
This approach simplifies the patch and "pg_compression" table could be
removed. So compression method is created with something like:
CREATE ACCESS METHOD .. TYPE COMPRESSION HANDLER
awesome_compression_handler;
Syntax of SET COMPRESSION changes to SET COMPRESSION .. PRESERVE which
is useful to control rewrites and for pg_upgrade to make dependencies
between moved compression options and compression methods from pg_am
table.
Default compression is always pglz and if users want to change they run:
ALTER COLUMN <col> SET COMPRESSION awesome PRESERVE pglz;
Without PRESERVE it will rewrite the whole relation using new
compression. Also the rewrite removes all unlisted compression options
so their compresssion methods could be safely dropped.
"pg_compression_opt" table could be renamed to "pg_compression", and
compression options will be stored there.
I'd like to keep extra compression options, for example pglz can be
configured with them. Syntax would be slightly changed:
SET COMPRESSION pglz WITH (min_comp_rate=25) PRESERVE awesome;
Setting the same compression method with different options will create
new compression options record for future tuples but will not
rewrite table.
--
----
Regards,
Ildus Kurbangaliev
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: <20171213151818.75a20259@postgrespro.ru>
* 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