Re: Different compression methods for FPI

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Different compression methods for FPI
Дата
Msg-id YMqjMyXA6NwiFeXg@paquier.xyz
обсуждение исходный текст
Ответ на Re: Different compression methods for FPI  (Andrey Borodin <x4mmm@yandex-team.ru>)
Ответы Re: Different compression methods for FPI  (Michael Paquier <michael@paquier.xyz>)
Re: Different compression methods for FPI  (Andrey Borodin <x4mmm@yandex-team.ru>)
Список pgsql-hackers
On Wed, Jun 16, 2021 at 01:17:26PM +0500, Andrey Borodin wrote:
> I agree that allowing just lz4 - is already a huge step ahead.

Yeah, I am tempted to just add LZ4 as a first step as the patch
footprint would be minimal, and we could come back to zstd once we
have more feedback from the field, if that's necessary.  As said
upthread, we have more flexibility with WAL than for the relation
data.

> But I'd suggest supporting zstd as well. Currently we only compress
> 8Kb chunks and zstd had no runaway to fully unwrap it's potential.
> In WAL-G we observed ~3x improvement in network utilisation when
> switched from lz4 to zstd in WAL archive compression.

You mean full segments here, right?  This has no need to be in core,
except if we want to add more compression options to pg_receivewal and
its friends?  That would be a nice addition, saying that.

> BTW we could get rid of whole hole-in-a-page thing if we would set
> lz4 as default. This could simplify FPI code.

Why would we do that?  We still need to support pglz as fallback if a
platform does not have LZ4, no?
--
Michael

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: A qsort template
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: A qsort template