pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: Jacob Champion <jchampion@timescale.com>
Cc: pgsql-hackers@postgresql.org, gkokolatos@pm.me, Michael Paquier <michael@paquier.xyz>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Peter Geoghegan <pg@bowt.ie>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Thomas Munro <thomas.munro@gmail.com>
Cc: Dipesh Pandit <dipesh.pandit@gmail.com>
Cc: Andrey Borodin <x4mmm@yandex-team.ru>
Cc: Mark Dilger <mark.dilger@enterprisedb.com>
Subject: Re: zstd compression for pg_dump
Date: Mon, 3 Apr 2023 23:26:09 +0200
Message-ID: <27eb89fc-8fdd-2988-0959-0af1d6d7a12a@enterprisedb.com> (raw)
In-Reply-To: <ZCsmSoiBMVfrlOXm@telsasoft.com>
References: <ZBKgBz+4blcKru6x@telsasoft.com>
	<0115b682-58f0-ea43-9ecd-c37a4495812e@enterprisedb.com>
	<ZCHSSv3DgxUa0f3L@telsasoft.com>
	<0022dd9e-a439-d72f-d09b-ec512c23949b@enterprisedb.com>
	<ZCdpzywVGl0BLan2@telsasoft.com>
	<4029fe58-f661-7d8d-cbbb-b936a05531e2@enterprisedb.com>
	<ZCd6sb7XA/W6nLaD@telsasoft.com>
	<2de3bcad-6da9-9022-bce5-fc0416351d6e@enterprisedb.com>
	<ZCgzbBVKLvwpqMzT@telsasoft.com>
	<f3947107-a95a-348c-263c-284ac7275ae0@enterprisedb.com>
	<ZCsmSoiBMVfrlOXm@telsasoft.com>



On 4/3/23 21:17, Justin Pryzby wrote:
> On Sat, Apr 01, 2023 at 10:26:01PM +0200, Tomas Vondra wrote:
>>> Feel free to mess around with threads (but I'd much rather see the patch
>>> progress for zstd:long).
>>
>> OK, understood. The long mode patch is pretty simple. IIUC it does not
>> change the format, i.e. in the worst case we could leave it for PG17
>> too. Correct?
> 
> Right, libzstd only has one "format", which is the same as what's used
> by the commandline tool.  zstd:long doesn't change the format of the
> output: the library just uses a larger memory buffer to allow better
> compression.  There's no format change for zstd:workers, either.
> 

OK. I plan to do a bit more review/testing on this, and get it committed
over the next day or two, likely including the long mode. One thing I
noticed today is that maybe long_distance should be a bool, not int.
Yes, ZSTD_c_enableLongDistanceMatching() accepts int, but it'd be
cleaner to cast the value during a call and keep it bool otherwise.

regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company





view thread (46+ messages)  latest in thread

Message-ID: <27eb89fc-8fdd-2988-0959-0af1d6d7a12a@enterprisedb.com>
Permalink:  ../27eb89fc-8fdd-2988-0959-0af1d6d7a12a@enterprisedb.com/
Also on:    postgresql.org/message-id/27eb89fc-8fdd-2988-0959-0af1d6d7a12a@enterprisedb.com

 · 

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: tomas.vondra@enterprisedb.com, pryzby@telsasoft.com, jchampion@timescale.com, michael@paquier.xyz, robertmhaas@gmail.com, pg@bowt.ie, peter.eisentraut@enterprisedb.com, hlinnaka@iki.fi, thomas.munro@gmail.com, dipesh.pandit@gmail.com, x4mmm@yandex-team.ru, mark.dilger@enterprisedb.com
  Subject: Re: zstd compression for pg_dump
  In-Reply-To: <27eb89fc-8fdd-2988-0959-0af1d6d7a12a@enterprisedb.com>

* 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