pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tomas Vondra <tomas.vondra@enterprisedb.com>
Cc: Andrey Borodin <x4mmm@yandex-team.ru>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Daniil Zakhlystov <usernamedt@yandex-team.ru>
Cc: Konstantin Knizhnik <k.knizhnik@postgrespro.ru>
Cc: Denis Smirnov <sd@arenadata.io>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: libpq compression
Date: Tue, 22 Dec 2020 14:33:22 -0500
Message-ID: <630701.1608665602@sss.pgh.pa.us> (raw)
In-Reply-To: <1f76b4b8-3bff-17af-ef63-872190411a60@enterprisedb.com>
References: <aad16e41-b3f9-e89d-fa57-fb4c694bec25@postgrespro.ru>
	<612f227d-cb27-9238-5922-1500f8b2eb96@postgrespro.ru>
	<160623927937.7563.15974279758478581796.pgcf@coridan.postgresql.org>
	<CA+TgmoY5AMq8auemc0g3geCpVDeRnawW1A-jUeqT-5cE-_2MiA@mail.gmail.com>
	<6811D196-E2FB-40CC-B1C9-F19427FBF675@yandex-team.ru>
	<CA+TgmoZMTLydjP3iWBir20OrSXTugxS2CXC1WP1nWM5=Zqz0Nw@mail.gmail.com>
	<A1D0D9A4-1FC4-4311-83C7-EEA90749EE07@yandex-team.ru>
	<CA+TgmoZrM9T_W9YR-vLYZXj-vC_+F-DER65A87+pDXRwUFjJXg@mail.gmail.com>
	<D5354E7A-3B9F-4D32-B3AB-F65058D36500@yandex-team.ru>
	<CCAB1F57-A71D-4DEC-9A9C-F325B44BAC29@arenadata.io>
	<93027ee4-fefa-a8ca-2cc7-245c912bf824@postgrespro.ru>
	<62527092-16BD-479F-B503-FA527AF3B0C2@yandex-team.ru>
	<CA+TgmoZbVH4R5JA9_pyTSdnFTq-w2B1JvomeD+r0oo0xp1DPtQ@mail.gmail.com>
	<d889e3a2-d3f4-3f8e-aa81-c142e32ddf57@enterprisedb.com>
	<AA76CFB9-2641-4630-9E33-87BE7B89E13B@yandex-team.ru>
	<579f308e-c46c-2e79-3f90-9846450a3d71@enterprisedb.com>
	<626075.1608663785@sss.pgh.pa.us>
	<1! f76b4b8-3bff-17af-ef63-872190411a60@enterprisedb.com>

Tomas Vondra <tomas.vondra@enterprisedb.com> writes:
> On 12/22/20 8:03 PM, Tom Lane wrote:
>> The link Ken pointed at suggests that restricting the window size to
>> 8MB is a common compromise.  It's not clear to me what that does to
>> the achievable compression ratio.  Even 8MB could be an annoying cost
>> if it's being paid per-process, on both the server and client sides.

> Possibly, but my understanding is that's merely a recommendation for the 
> decoder library (e.g. libzstd), and it's not clear to me if/how that 
> relates to the compression level or how to influence it.
>  From the results shared by Daniil, the per-client overhead seems way 
> higher than 8MB, so either libzstd does not respect this recommendation 
> or maybe there's something else going on.

I'd assume that there's a direct correlation between the compression level
setting and the window size; but I've not studied the libzstd docs in
enough detail to know what it is.

			regards, tom lane





view thread (289+ messages)  latest in thread

Message-ID: <630701.1608665602@sss.pgh.pa.us>
Permalink:  ../630701.1608665602@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/630701.1608665602@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tgl@sss.pgh.pa.us, tomas.vondra@enterprisedb.com, x4mmm@yandex-team.ru, robertmhaas@gmail.com, usernamedt@yandex-team.ru, k.knizhnik@postgrespro.ru, sd@arenadata.io, pgsql-hackers@lists.postgresql.org
  Subject: Re: libpq compression
  In-Reply-To: <630701.1608665602@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox