Re: Zstandard support for toast compression

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael Paquier <michael(at)paquier(dot)xyz>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Zstandard support for toast compression
Date: 2022-05-19 10:40:27
Message-ID: CAA4eK1JWb7jqSdsL0OT+=tue16UaFGRRm4wyGRdaxf+PmSrp+Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, May 18, 2022 at 9:47 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> I do understand that Zstandard is a good compression algorithm, and if
> we had an extensibility mechanism here where one of the four possible
> bit patterns then indicates that the next byte (or two or four) stores
> the real algorithm type, then what about adding Zstandard that way
> instead of consuming one of our four primary bit patterns? That way
> we'd have this option for people who want it, but we'd have more
> options for the future instead of fewer.
>
> i.e. something like:
>
> 00 = PGLZ
> 01 = LZ4
> 10 = reserved for future emergencies
> 11 = extended header with additional type byte (1 of 256 possible
> values reserved for Zstandard)
>

+1 for such an extensible mechanism if we decide to go with Zstandard
compression algorithm. To decide that won't it make sense to see some
numbers as Michael already has a patch for the new algorithm?

--
With Regards,
Amit Kapila.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrey Lepikhov 2022-05-19 10:48:18 Re: Removing unneeded self joins
Previous Message Alvaro Herrera 2022-05-19 10:21:58 Re: Intermittent buildfarm failures on wrasse