Horton

Re: [HACKERS] Custom compression methods

Dilip Kumar <dilipbalaut@gmail.com>

View thread View on postgr.es
From: Dilip Kumar <dilipbalaut@gmail.com>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, Alexander Korotkov <a.korotkov@postgrespro.ru>, David Steele <david@pgmasters.net>, Ildus Kurbangaliev <i.kurbangaliev@gmail.com>, Dmitry Dolgov <9erthalion6@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-03-12T04:22:23Z
Lists: pgsql-hackers 
On Fri, Mar 12, 2021 at 2:54 AM Justin Pryzby <pryzby@telsasoft.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@telsasoft.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

Commits

  1. docs: Update TOAST storage docs for configurable compression.

  2. Further tweaking of pg_dump's handling of default_toast_compression.

  3. Fix interaction of TOAST compression with expression indexes.

  4. Tidy up more loose ends related to configurable TOAST compression.

  5. Short-circuit slice requests that are for more than the object's size.

  6. Mostly-cosmetic adjustments of TOAST-related macros.

  7. Remove useless configure probe for <lz4/lz4.h>.

  8. Error on invalid TOAST compression in CREATE or ALTER TABLE.

  9. docs: Fix omissions related to configurable TOAST compression.

  10. More code cleanup for configurable TOAST compression.

  11. Bring configure support for LZ4 up to snuff.

  12. Make compression.sql regression test independent of default.

  13. Use valid compression method in brin_form_tuple

  14. Fix up pg_dump's handling of per-attribute compression options.

  15. Allow configurable LZ4 TOAST compression.

  16. Fix inconsistencies in the code

  17. Mostly-cosmetic improvements in memory chunk header alignment coding.

  18. Allow numeric to use a more compact, 2-byte header in many cases.