Re: Different compression methods for FPI

From: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
To: Justin Pryzby <pryzby(at)telsasoft(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Different compression methods for FPI
Date: 2021-03-06 07:29:14
Message-ID: C57172E1-B9D7-4FDA-BCAB-76FEEFCBA603@yandex-team.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> 1 марта 2021 г., в 10:03, Justin Pryzby <pryzby(at)telsasoft(dot)com> написал(а):

Justin, Michael, thanks for comments!

As far as I understood TODO list for the patch looks as follows:

1. Reuse compression API of other patches. But which one? Or should I invent new one? "compressamapi.h" from "custom compression methods" bothers only with varlena <-> varlena conversions, and only for lz4. And it is "access method" after all, residing in backend...
ZStream looks good, but it lacks OID identification for compression methods and lz4.
2. Store OID in FPIs instead of 1-byte CompressionId. Make sure frontend is able to recognize builtin compression OIDs.
3. Complain if wal_compression_method is set to lib which is not compiled in.
4. Add tests for different WAL compression methods similar to src/test/ssl

Did I miss something?
I would appreciate a help with item 1, I do not know how to choose starting point.

> wal_compression_method (why not just using wal_compression?)

I hope one day we will compress all WAL, not just FPIs. Advanced archive management tools already do so, why not compress it in walwriter?
When this will be implemented, we could have wal_compression = {off, fpi, all}.

Best regards, Andrey Borodin.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message osumi.takamichi@fujitsu.com 2021-03-06 07:55:44 RE: [HACKERS] logical decoding of two-phase transactions
Previous Message Joel Jacobson 2021-03-06 05:03:30 Re: Some regular-expression performance hacking