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
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 |