Hello,
On Tue, 2023-10-03 at 08:57 +0900, Michael Paquier wrote:
> On Mon, Oct 02, 2023 at 04:42:15PM +0200, Dominique Devienne wrote:
> > According to the doc, the table is NOT changed.
> > In my case, I DO want to have the bytea column rewritten
> > according to the new STORAGE and/or COMPRESSION.
> > The doc doesn't mention how to achieve that.
>
> Yes, the compression type of the existed toasted values are not
> changed after an ALTER SET, and that's not something one would do on
> a
> daily basis, either.
>
> > VACUUM?
> > VACUUM FULL?
> > Else?
>
> VACUUM was considered as an option to force a rewrte, but it has been
> removed because we were not sure that this is the correct path to do
> so or that in some cases forcing the hand of the user was incorrect.
> It was also creating a penalty in some of the hot loops of area:
> commit: dbab0c07e5ba1f19a991da2d72972a8fe9a41bda
> committer: Michael Paquier <michael@paquier.xyz>
> date: Mon, 14 Jun 2021 09:25:50 +0900
> Remove forced toast recompression in VACUUM FULL/CLUSTER
>
> Related thread:
> https://postgr.es/m/20210527003144.xxqppojoiwurc2iz@alap3.anarazel.de
> --
> Michael
Would running CLUSTER on the table use the new parameters for the re-
write?
The docs about CLUSTER do not mention anything about toast'ed data. If
the toast data is huge it would be held in a separate file on disk. If
the toast column is being compressed, and its size is now less than the
value used as to whether a separate file is required or not, will the
outcome be a single row for the re-write and deletion of the "old"
toast'ed entry?
Robert
