Re: Toast compression method options

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Toast compression method options
Date: 2021-06-22 08:07:23
Message-ID: YNGaO7yJnNIgf1Go@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jun 22, 2021 at 11:05:22AM +0530, Dilip Kumar wrote:
> IMHO there is certainly a use case, basically, if we compress the data
> so that we can avoid storing it externally. Now suppose for some
> data, with default LZ4 compression, the compression ratio is so high
> that you are able to compress to the size which is way under the
> limit. So for such data, the acceleration can be increased such that
> compression is fast and compression ratio is good enough that it is
> not going to the external storage. I agree it will be difficult for
> the user to make such a decision and select the acceleration value but
> based on the data pattern and their compressed length the admin can
> make such a decision. So in short select the acceleration value such
> that you can compress it fast and the compression ratio is good enough
> to keep it from storing externally.

Theoritically, I agree that there could be a use case, and that was
the point I was trying to outline above. My point is more from a
practical point of view. LZ4 is designed to be fast and cheap in CPU
with a rather low compression ratio compared to other modern algos.

Could it be possible to think about some worst cases where one may
want to reduce its compression to save some CPU? The point, as you
say, to allow a tuning of the acceleration would be that one may want
to save a bit of CPU and does not care about the extra disk space it
takes. Still, I am wondering why one would not just store the values
externally in such cases and just save as much compression effort as
possible.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2021-06-22 08:17:26 Re: improvements in Unicode tables generation code
Previous Message Peter Eisentraut 2021-06-22 07:20:16 improvements in Unicode tables generation code