Re: Flexible pglz_stategy values and delete const.

Hello.

On Tue, Feb 18, 2020 at 1:20 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Mon, Feb 17, 2020 at 11:04:47AM +0900, Moon, Insung wrote:
> > The compression-related strategy is applied only when compressed.
> > Decompression does not use strategy, so the old compressed data is not
> > affected by the new patch.
>
> This may be a difficult question, but do you have examples of
> workloads which could benefit of having such reloptions? It is not
> the kind of options which are easy to tune, still a POC should be
> simple enough to implement to show your point.

Thank you for your response.
In fact, I have not a very specific workload,
but for the sake of simplicity test workload, I'm created TOAST data
using my PoC to check if compression was successful.

For default pglz_strategy ...
=# create table foo (i text);
=# insert INTO foo values (random_string_simple (10000));
# random_string_simple function is that generates random numbers(text)
from 0 to 9.
result = Compression failure [10000]
# This is the log I added, if compression failed.

For change pglz_strategy in the made POC ...
(Here I set the min_comp_rate strategy more loosely 25 to 10)
=# Insert INTO foo values (random_string_simple (10000));
result = Compression Success [10000] [7631]
Compression was successful, and data was reduced from 10000byte to
7631byte(about 24%), including the TOAST header.

In other words, such a case may occur, and instead of compressing with
a fixed strategy,
I want to give a choice to users who need a compression strategy.
Of course, compression may cause performance degradation, but some
users may want to minimize disk usage.
And, in the case of FPW, there are more cases where the size of the
WAL is smaller, so there may be cases in which the SR environment is
advantageous.

I will send my POC for testing and discussing it as soon as possible.
Of course, test modules and documentation modifications are not included.

Best regards.
Moon.

> --
> Michael