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@xxxxxxxxxxx> > 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@xxxxxxxxxxxxxxxxx > -- > 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
