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.
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 |