From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, pgsql-hackers(at)postgresql(dot)org, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, Andres Freund <andres(at)anarazel(dot)de> |
Subject: | Re: Different compression methods for FPI |
Date: | 2021-06-16 00:39:57 |
Message-ID: | YMlIXTq+aLidW96K@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jun 15, 2021 at 11:14:56AM -0500, Justin Pryzby wrote:
> You're right, I hadn't though this through all the way.
> There's precedent if the default is non-static (wal_sync_method).
>
> But I think yes/on/true/1 should be a compatibility alias for a static thing,
> and then the only option is pglz.
>
> Of course, changing the default to LZ4 is still a possibility.
We have not reached yet a conclusion with the way we are going to
parameterize all that, so let's adapt depending on the feedback. For
now, I am really interested in this patch set, so I am going to run
some tests of my own and test more around the compression levels we
have at our disposals with the proposed algos.
From I'd like us to finish with here is one new algorithm method, able
to cover a large range of cases as mentioned upthread, from
low-CPU/low-compression to high-CPU/high-compression. It does not
seem like a good idea to be stuck with an algo that only specializes
in one or the other, for example.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Julien Rouhaud | 2021-06-16 01:11:22 | Re: Duplicate history file? |
Previous Message | Andres Freund | 2021-06-16 00:20:46 | Re: snapshot too old issues, first around wraparound and then more. |