Re: [HACKERS] Custom compression methods

From: Ildar Musin <ildar(at)adjust(dot)com>
To: Ildus Kurbangaliev <i(dot)kurbangaliev(at)gmail(dot)com>
Cc: David Steele <david(at)pgmasters(dot)net>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [HACKERS] Custom compression methods
Date: 2019-03-18 16:11:01
Message-ID: CAONYFtNfWbFEUM1NHGeb0yY6LTsAjTB-H-famR6k4xKf+fCfRQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Ildus,

On Fri, Mar 15, 2019 at 12:52 PM Ildus Kurbangaliev <
i(dot)kurbangaliev(at)gmail(dot)com> wrote:

>
> Hi,
> in my opinion this patch is usually skipped not because it is not
> needed, but because of its size. It is not hard to maintain it until
> commiters will have time for it or I will get actual response that
> nobody is going to commit it.
>
> Attached latest set of patches.
>
>
As I understand, the only thing changed since my last review is an
additional
compression method for zlib.

The code looks good. I have one suggestion though. Currently you only
predefine
two compression levels: `best_speed` and `best_compression`. But zlib itself
allows a fine gradation between those two. It is possible to set level to
the
values from 0 to 9 (where zero means no compression at all which I guess
isn't
useful in our case). So I think we should allow user choose between either
textual representation (as you already did) or numeral. Another thing is
that one
can specify, for instance, `best_speed` level, but not `BEST_SPEED`, which
can
be a bit frustrating for user.

Regards,
Ildar Musin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2019-03-18 16:53:22 Concurrency bug with vacuum full (cluster) and toast
Previous Message Robert Haas 2019-03-18 15:47:26 Re: Add exclusive backup deprecation notes to documentation