Re: Move pg_attribute.attcompression to earlier in struct for reduced size?

On Thu, May 27, 2021 at 7:04 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > On Thu, May 27, 2021 at 12:11 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> AFAIR, there are zero promises about how effective, or when effective,
> >> changes in SET STORAGE will be. And the number of complaints about
> >> that has also been zero. So I'm not sure why we need to do more for
> >> SET COMPRESSION. Especially since I'm unconvinced that recompressing
> >> everything just to recompress everything would *ever* be worthwhile.
>
> > I think it is good to have *some* way of ensuring that what you want
> > the system to do, it is actually doing. If we have not a single
> > operation in the system anywhere that can force recompression, someone
> > who actually cares will be left with no option but a dump and reload.
> > That is probably both a whole lot slower than something in the server
> > itself and also a pretty silly thing to have to tell people to do.
>
> [ shrug... ] I think the history of the SET STORAGE option teaches us
> that there is no such requirement, and you're inventing a scenario that
> doesn't exist in the real world.

But can we compare SET STORAGE with SET compression? I mean storage
just controls how the data are stored internally and there is no
external dependency. But if we see the compression it will have a
dependency on the external library. So if the user wants to get rid
of the dependency on the external library then IMHO, there should be
some way to do it by recompressing all the data.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com