| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, 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> |
| Subject: | Re: Different compression methods for FPI |
| Date: | 2021-06-15 01:07:12 |
| Message-ID: | 20210615010712.b7ljwsrzw4y2whon@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2021-06-15 09:50:41 +0900, Michael Paquier wrote:
> On Sun, Jun 13, 2021 at 08:24:12PM -0500, Justin Pryzby wrote:
> > I think it's more nuanced than just finding the algorithm with the least CPU
> > use. The GUC is PGC_USERSET, and it's possible that a data-loading process
> > might want to use zlib for better compress ratio, but an interactive OLTP
> > process might want to use lz4 or no compression for better responsiveness.
>
> It seems to me that this should be a PGC_SUSET, at least? We've had
> our share of problems with assumptions behind data leaks depending on
> data compressibility (see ssl_compression and the kind).
-1.
Currently wal_compression has too much overhead for some workloads, but
not for others. Disallowing normal users to set it would break cases
where it's set for users that can tolerate the perf impact (which I have
done at least). And the scenarios where it can leak information that
couldn't otherwise be leaked already don't seem all that realistic?
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kyotaro Horiguchi | 2021-06-15 01:20:37 | Re: Duplicate history file? |
| Previous Message | Masahiko Sawada | 2021-06-15 01:06:49 | Re: PG 14 release notes, first draft |