Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vnJL5-004y6L-1c for pgsql-admin@arkaria.postgresql.org; Tue, 03 Feb 2026 16:33:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vnJL4-006Dcz-1Y for pgsql-admin@arkaria.postgresql.org; Tue, 03 Feb 2026 16:33:18 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vnJL3-006Dcr-3D for pgsql-admin@lists.postgresql.org; Tue, 03 Feb 2026 16:33:17 +0000 Received: from mail-oi1-x235.google.com ([2607:f8b0:4864:20::235]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1vnJL2-00000000Nyt-0DqO for pgsql-admin@postgresql.org; Tue, 03 Feb 2026 16:33:16 +0000 Received: by mail-oi1-x235.google.com with SMTP id 5614622812f47-45efe81556fso3927080b6e.2 for ; Tue, 03 Feb 2026 08:33:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1770136395; cv=none; d=google.com; s=arc-20240605; b=HmbiCEsZXrkpzxajv3k1SljrpX3C372z5m40jPnBWmfYA3fB5gAx0ZC6qbWh34uqW4 Id9H04izrpdb6VI52pidnQpBM1MnUK/7u0b80afsxjsYHX0OgSUWhMHIvO4t5lExJAEC RAGWAavnLjLu9agA+bHT0gv6rOWjN34z+lYyHpKUbePHC8Ihly7O405PzgkSeJLqmE9B ZYScQe6Bh6OEpE3aL+12XT16cB/6mFckT5Zr/Ct4k2gn09+jxJ4oDwU0SzLQ9QGfFnhs IXmCa9LSjowbD3MiF5pjJWMUY/2WFWUURpRIQ7faz+Omd2OwTNZzhMUmVOY/is7TQmVT W4gA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=y0ngRHwKP5Meb4/BJH8q42qwK7MkRplGnV0Wqrnvv+U=; fh=VNFPIRXc7M0wJPUs92j8fex2QaQptoCwDcumestTEpo=; b=MrwTeVA2Tt/P2Ol/FttkotiFeBOi66Bfj7JJPeDpQwLydhQlDW4ko+7vQ32tL6GBIt vslPFyq6Uj+OyzYOQV3lGNj9R7deTyeBOnggXkYs1FFAjYr61tBI3ytvklDrSrp8CdEY 5LrNWOwlkYZuBmG9+nc1UGODs7w0LQ+HXs6BsEZy55v+53YHa+Z9keO9vZZj+yk1cjo5 9gOZqQqL3zhpl4PenVB/7++zgXl3M62lGGjy+ZYpzaXichjvdOcjz18qd60qXD/I0eaJ v+BNvonIRR8px2aBLlcHyzKK5rVRw1aPhf+GQ2n9gDFMkW5P7MbquWwDIBqvcrjyZeMl uq+w==; darn=postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770136395; x=1770741195; darn=postgresql.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=y0ngRHwKP5Meb4/BJH8q42qwK7MkRplGnV0Wqrnvv+U=; b=jsGfXWeCuQ8l95Tz0orYiF0J3ltdS3VBuBUKkFV5IgmzpN812vYtYcpU7k+ZaQsNwK pSfH85aooay0MlrDSoev+IFtOqWV/UNtOFnsbH5EQKz/YOSt3CXIZxggsoK68qViE6iP RwnqnlJDTC9nfzZBiGbOWfm0On8yNKkEYGjJVkl0wMW94ocD9DGen4S4kStUSBoSo8h4 o1wSB4aPunnMOzroChowoC9xLsWebZRZXXVK6rxxxTT2GfxYpBc5NNoSRB3hr914ebCo j4Uyt0Of5lZDfK/E+nfvs57Q+QhW8xRprIjwWFkLQlKMi7shJqDUF4Jrk1Xf6rorjgJd aa6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770136395; x=1770741195; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=y0ngRHwKP5Meb4/BJH8q42qwK7MkRplGnV0Wqrnvv+U=; b=Nlxuc6IP0vgr+qz0px7Kj+svaOlHdYMuBLeAeHA5ESUBUhDOKBgfU6qp/ntRMt51ny NsJMMLLplU195jz1+U1cEmjZ8REkL3i8JYXgB4Aa7jODd3qhxZYa/OVkfK7WgaxaRtV2 I+lmjx6qpy3LJhkgZcvYmQtWrMo1OwOVFzbNe3Fb1ASnflETMMjm1P+vvguhbvQCb5SM cIhMWT6ke2atiMDP2JpNwLxYaoGdC9WRfBxlRntjHmKlHbrfuaUhpd+DV/SCoizQwQ91 zv+klwRUyTj+5lR7vrdvivFbjDkC9RRSl4YzNtjpRaLHb+TlW1QD5sHZskLaDplemXal xc4A== X-Gm-Message-State: AOJu0YyMJr8v1hHKUKWAsoZF7bLr5L8A2QoJ9U+u9ZEDQk4SeBw1Pn2j eDwbFVEC3FKTLLGLC/lb7x1tjuPhKd/VTpQcNSG+FL3qmRuRHkHZu8a8lXotSEuCpZ/CyxOab8Z 33fva9jOylmWeDZWC43Jy4CRXruuvRVxyqQ== X-Gm-Gg: AZuq6aIRhzcCWQb2g5VfNW1t5yuZfJmLARBQfrYsDBFTlxE52FNeu3uFe76gYgve3fm ipNwfvzER1AkLepUn4ZyE6PchEvoK3AEo1mBQccA9tTwU6oXOrGqzocHGrE/rtZso7GWeczgzJ2 W3xdMiazQSEQNsXbjD7LXoqYY8ISA8YgzPXI3PCW4Dpfpef3sIrvsHH4RCNex7J29uT3DQkdO3V GOpYCvZcrq1KkokrMwxAkljt421Ek+SQyrwRYOVc9L9oieaZfTkzEDBQnmGlXOXE9F1d1QTNOU1 O/RxCU0= X-Received: by 2002:a05:6808:4fd1:b0:45f:48a:ac1b with SMTP id 5614622812f47-45f34bb27a1mr8094750b6e.20.1770136395103; Tue, 03 Feb 2026 08:33:15 -0800 (PST) MIME-Version: 1.0 References: <6bff91db-843e-4858-95dd-cc8bfb90c012@jakobs.com> <240b5c920d864da8157e65f8b7683c6a5e6d8aae.camel@cybertec.at> In-Reply-To: From: Ron Johnson Date: Tue, 3 Feb 2026 11:33:04 -0500 X-Gm-Features: AZwV_QiZCcuICDL-CRqkvQfhYhTQ5oy47gFY3QYbBlMN7My3Y1dfGTg2vVRCEjU Message-ID: Subject: Re: Does pg_dump custom format only compress the table data? To: pgsql-admin Content-Type: multipart/alternative; boundary="00000000000008c1b60649edff39" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000008c1b60649edff39 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 3, 2026 at 11:16=E2=80=AFAM Ron Johnson wrote: > On Tue, Feb 3, 2026 at 7:48=E2=80=AFAM Laurenz Albe > wrote: > >> On Tue, 2026-02-03 at 08:51 +0100, Holger Jakobs wrote: >> > Am 03.02.26 um 07:06 schrieb Laurenz Albe: >> > > On Mon, 2026-02-02 at 10:55 -0500, Ron Johnson wrote: >> > > > Out of curiosity, I opened that dump file in vim, and saw not only >> DDL strings but cleartext table data. >> > > > >> > > > Why isn't it compressed? >> > > Are your DDL statement large enough that you would expect that >> compressing >> > > them would offer any real advantage? >> > >> > That wasn't the question. It was about why table DATA aren't >> compressed, >> > but in clear text. >> >> Ah, I see. >> >> By default, you wouldn't see any table data, because they get compressed= . >> >> If a custom format dump is not compressed, the reason could be: >> >> - PostgreSQL was built without support for compression (--without-zlib) >> >> - pg_dump was called with --compress=3D0 >> > > I always install RPMs from postgresql.org, and in this case specified > --compress=3Dzstd:long. > > $ psql -V > psql (PostgreSQL) 17.7 > > dba=3D# insert into do_not_delete (node_name) values ('foo'); > INSERT 0 1 > dba=3D# insert into do_not_delete (node_name) values ('bar'); > INSERT 0 1 > dba=3D# insert into do_not_delete (node_name) values ('blarge'); > INSERT 0 1 > dba=3D# > > $ pg_dump -V > pg_dump (PostgreSQL) 17.7 > > db=3Ddba > $ pg_dump -Fc --compress=3Dzstd:long -v -d${db} -f ${db}.dump 2> ${db}.l= og > $ dir ${db}.dump > -rw-r--r-- 1 postgres postgres 2205102870 2026-02-03 11:07:34 dba.dump > > $ strings ${db}.dump | grep -E 'foo|bar|blarge' > foo \N > bar \N > blarge \N > \Afoo > barYD > [snip] > I tested more. The default gzip compression does in fact compress everything. This must be a quirk of zstd. --=20 Death to , and butter sauce. Don't boil me, I'm still alive. lobster! --00000000000008c1b60649edff39 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Feb 3, 2026 at 11:16=E2=80=AFAM R= on Johnson <ronljohnsonjr@gma= il.com> wrote:
On Tue, Feb 3, 2026 at 7:48=E2=80=AFAM Laurenz Albe <laurenz.albe@cyberte= c.at> wrote:
On Tue, 2026-02-03 at 08:51 +0100, Holger Jakobs= wrote:
> Am 03.02.26 um 07:06 schrieb Laurenz Albe:
> > On Mon, 2026-02-02 at 10:55 -0500, Ron Johnson wrote:
> > > Out of curiosity, I opened that dump file in vim, and saw no= t only DDL strings but cleartext table data.
> > >
> > > Why isn't it compressed?
> > Are your DDL statement large enough that you would expect that co= mpressing
> > them would offer any real advantage?
>
> That wasn't the question. It was about why table DATA aren't c= ompressed,
> but in clear text.

Ah, I see.

By default, you wouldn't see any table data, because they get compresse= d.

If a custom format dump is not compressed, the reason could be:

- PostgreSQL was built without support for compression (--without-zlib)

- pg_dump was called with --compress=3D0

I always install RPMs from postgresql.org, and in this case specified --compress=3Dzstd:long= .

$ psql -V
psql (Post= greSQL) 17.7

dba=3D# insert into do_not_delete (node_name) values (&= #39;foo');
INSERT 0 1
dba=3D# insert into do_not_delete (node_nam= e) values ('bar');
INSERT 0 1
dba=3D# insert into do_not_dele= te (node_name) values ('blarge');
INSERT 0 1
dba=3D#

= $ pg_dump -V
pg_dump (PostgreSQL) 17.7

db=3Ddba
$ pg_dump -Fc = --compress=3Dzstd:long -v -d${db} -f ${db}.dump =C2=A02> ${db}.log
$ = dir ${db}.dump
-rw-r--r-- 1 postgres postgres 2205102870 2026-02-03 11:0= 7:34 dba.dump

$ strings ${db}.dump | grep -E 'foo|bar|blarge'= ;
foo =C2=A0 =C2=A0 \N
bar =C2=A0 =C2=A0 \N
blarge =C2=A0\N
\Af= oo
barYD
[snip]
=C2=A0
I tested more.=C2=A0 The default gzip compression does in fact compre= ss everything.=C2=A0 This must be a quirk of zstd.

--
Death to <Redacted>, and butt= er sauce.
Don't boil me, I'm still alive.
<Reda= cted> lobster!
--00000000000008c1b60649edff39--