Re: [HACKERS] Custom compression methods

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>
Cc: Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Ildus Kurbangaliev <i(dot)kurbangaliev(at)postgrespro(dot)ru>, Ildar Musin <i(dot)musin(at)postgrespro(dot)ru>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Евгений Шишкин <itparanoia(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Oleg Bartunov <obartunov(at)gmail(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Chapman Flack <chap(at)anastigmatix(dot)net>
Subject: Re: [HACKERS] Custom compression methods
Date: 2018-06-19 14:57:37
Message-ID: CA+TgmoazcTRNWacQ3Lwnrp_u7WyEC3r7o6zZ+rpmfaZez+kOug@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Apr 23, 2018 at 12:34 PM, Konstantin Knizhnik
<k(dot)knizhnik(at)postgrespro(dot)ru> wrote:
> May be. But in any cases, there are several direction where compression can
> be used:
> - custom compression algorithms
> - libpq compression
> - page level compression
> ...
>
> and them should be somehow finally "married" with each other.

I agree that we should try to avoid multiplying the number of
compression-related APIs. Ideally there should be one API for
registering a compression algorithms, and then there can be different
methods of selecting that compression algorithm depending on the
purpose for which it will be used. For instance, you could select a
column compression format using some variant of ALTER TABLE ... ALTER
COLUMN, but you would obviously use some other method to select the
WAL compression format. However, it's a little unclear to me how we
would actually make the idea of a single API work. For column
compression, we need everything to be accessible through the catalogs.
For something like WAL compression, we need it to be completely
independent of the catalogs. Those things are opposites, so a single
API can't have both properties. Maybe there can be some pieces
shared, but as much as I'd like it to be otherwise, it doesn't seem
possible to share it completely.

I also agree with Ildus and Alexander that we cannot and should not
try to solve every problem in one patch. Rather, we should just think
ahead, so that we make as much of what goes into this patch reusable
in the future as we can.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2018-06-19 15:06:22 Re: WAL prefetch
Previous Message Tom Lane 2018-06-19 14:55:10 Fast default stuff versus pg_upgrade