Re: [HACKERS] Custom compression methods

On Fri, Mar 12, 2021 at 2:54 AM Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:
>
> On Thu, Mar 11, 2021 at 10:07:30AM +0530, Dilip Kumar wrote:
> > 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 mean to keep the current behavior where SET is only a catalog change.
> But I'm comparing with earlier implementation.
>
> Does your new patch avoid recompressing things if the compression is unchanged?

Currently, my patch is not at all re-compressing on ALTER SET
COMPRESSION METHOD. Yesterday I had an offlist discussion with Robert
and the idea is that whenever we are rewriting the table that time we
can use the opportunity to compare the compression method of the
compressed data with the current compression method of the attribute,
and if they are not the same then decompress so that they can be
compressed back as per the current compression method if required. So
that will be true for VACUUM FULL, CLUSTER, INSERT INTO SELECT,
MATVIEW, CTAS. I think for alter table also if we are rewriting a
table for some reason then we can use the opportunity to re-compress,
but we are not planning to force a rewrite for ALTER SET COMPRESSION,
even if we are changing the compression method. I will make all these
changes in the next version of the patch.

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