Re: BUG #17513: recompressing already-compressed data via VACUUM FULL or CLUSTER does not work
От | Michael Paquier |
---|---|
Тема | Re: BUG #17513: recompressing already-compressed data via VACUUM FULL or CLUSTER does not work |
Дата | |
Msg-id | YqFInCwQCvMAg3/+@paquier.xyz обсуждение исходный текст |
Ответ на | Re: BUG #17513: recompressing already-compressed data via VACUUM FULL or CLUSTER does not work ("David G. Johnston" <david.g.johnston@gmail.com>) |
Список | pgsql-bugs |
On Wed, Jun 08, 2022 at 03:59:51PM -0700, David G. Johnston wrote: > The described behavior didn't even make it into 14.0; and I have no clue > where such a thing would be documented to guess if the lack was intentional > or not. I can confirm that as of today the behavior in HEAD is to not > decompress and recompress during rewrite. Frankly, this seems like the > expected behavior absent any documentation to the contrary. Whether there > is a use case for someone to code up a way to get a recompression to happen > is another matter. Oddly, I kinda expected that "update cmdata set f1 = > f1;" might do it but alas it does not (...set f1 = f1 || ''... works; I'm > not quite sure how much worse that, immediately followed by vacuum full, > would be compared to whatever it would take to do it all during the full > vacuum...especially if one is changing every single row on the table). See commit dbab0c0 about the reasons of this choice, with this thread: https://www.postgresql.org/message-id/20210527003144.xxqppojoiwurc2iz@alap3.anarazel.de The docs of ALTER TABLE .. SET COMPRESSION include a note on the matter: https://www.postgresql.org/docs/14/sql-altertable.html "This does not cause the table to be rewritten, so existing data may still be compressed with other compression methods." -- Michael
Вложения
В списке pgsql-bugs по дате отправления: