Re: Toast compression method options
От | Michael Paquier |
---|---|
Тема | Re: Toast compression method options |
Дата | |
Msg-id | YNGaO7yJnNIgf1Go@paquier.xyz обсуждение исходный текст |
Ответ на | Re: Toast compression method options (Dilip Kumar <dilipbalaut@gmail.com>) |
Ответы |
Re: Toast compression method options
|
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: