Feedback-ID: ia2694551:Fastmail
Date: Fri, 21 Mar 2025 15:39:17 +0100
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Cc: vignesh C <vignesh21@gmail.com>, Michael Paquier <michael@paquier.xyz>,
	Daniel Gustafsson <daniel@yesql.se>, Tom Lane <tgl@sss.pgh.pa.us>,
	Peter Eisentraut <peter@eisentraut.org>,
 PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Test to dump and restore objects left behind by regression
Message-ID: <202503211439.6mflw7yaomfq@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CAExHW5uqYJGTSDJFCTA1+9d_nhxGJb7=1aFZu6uCdJbvhpO7cQ@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/202503211439.6mflw7yaomfq%40alvherre.pgsql>
Precedence: bulk

I passed PROVE_FLAGS="--timer -v" to get the timings and run under
--format=directory.

Without new test:
ok    23400 ms ( 0.00 usr  0.00 sys +  2.84 cusr  1.53 csys =  4.37 CPU)
ok    23409 ms ( 0.00 usr  0.01 sys +  2.81 cusr  1.53 csys =  4.35 CPU)


With new test, under --format=directory:
-j2 (parallel, default gzip compression)
ok    27517 ms ( 0.00 usr  0.00 sys +  3.92 cusr  1.86 csys =  5.78 CPU)
ok    27772 ms ( 0.01 usr  0.00 sys +  3.96 cusr  1.86 csys =  5.83 CPU)
ok    27654 ms ( 0.00 usr  0.00 sys +  3.81 cusr  1.94 csys =  5.75 CPU)
ok    27663 ms ( 0.00 usr  0.00 sys +  4.11 cusr  1.71 csys =  5.82 CPU)

-j2 --compress=0
ok    27710 ms ( 0.00 usr  0.00 sys +  3.79 cusr  1.86 csys =  5.65 CPU)
ok    27567 ms ( 0.01 usr  0.00 sys +  3.67 cusr  1.96 csys =  5.64 CPU)
ok    27582 ms ( 0.00 usr  0.00 sys +  3.60 cusr  1.90 csys =  5.50 CPU)
ok    27519 ms ( 0.01 usr  0.00 sys +  3.71 cusr  1.80 csys =  5.52 CPU)

-j2 --compress=zstd
ok    27240 ms ( 0.01 usr  0.00 sys +  3.65 cusr  2.10 csys =  5.76 CPU)
ok    27301 ms ( 0.01 usr  0.00 sys +  3.77 cusr  1.97 csys =  5.75 CPU)

-j2 --compress=zstd:1
ok    27695 ms ( 0.01 usr  0.00 sys +  3.66 cusr  2.05 csys =  5.72 CPU)
ok    27671 ms ( 0.01 usr  0.00 sys +  3.76 cusr  1.95 csys =  5.72 CPU)

--compress=zstd:1 (no parallelism)
ok    28417 ms ( 0.01 usr  0.00 sys +  3.90 cusr  1.75 csys =  5.66 CPU)
ok    28388 ms ( 0.00 usr  0.00 sys +  3.74 cusr  1.81 csys =  5.55 CPU)

--compress=zstd (no parallelism)
ok    28310 ms ( 0.00 usr  0.01 sys +  3.81 cusr  1.83 csys =  5.65 CPU)
ok    28277 ms ( 0.01 usr  0.00 sys +  3.71 cusr  1.87 csys =  5.59 CPU)


So apparently, zstd if available is a bit better than gzip and
parallelism is better than no.  But the differences are small -- half a
second or so.  The total increase in runtime in the best case is about
four seconds.  In all cases I used the same parallelism in pg_restore
than pg_dump; not sure if that could cause a difference.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/