Re: [HACKERS] Custom compression methods

On Thu, Mar 11, 2021 at 8:50 AM Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:
>
> Looking at v23-0002-alter-table-set-compression, ATRewriteTable() was calling
> CompareCompressionMethodAndDecompress().

While changing the compression method user might be just interested
to compress the future tuple with the new compression method but
doesn't want to rewrite all the old tuple. So IMHO without any option
just force
rewrite whenever changing the compression method doesn't look that
great.

> I think what's wanted here is that decompression should only happen when the
> tuple uses a different compression than the column's currently set compression.
> So there's no overhead in the usual case. I guess CLUSTER and INSERT SELECT
> should do the same.
>
> This is important to allow someone to get rid of LZ4 compression, if they want
> to get rid of that dependency.
>
> But it's also really desirable for admins to be able to "migrate" existing
> data. People will want to test this, and I guess INSERT SELECT and CLUSTER are
> the obvious ways.

For INSERT SELECT we were already doing in the older version so we can
include that code here, we will also have to include the patches for
decompressing data before forming the composite types because without
that we can not ensure that lz4 does not exist anywhere in the table.
Said that with that also we can not ensure that it doesn't exist anywhere
in the system because it might exist in the WAL and if you do the crash
recovery then might get those lz4 compressed data back.

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