Re: Test to dump and restore objects left behind by regression
Alvaro Herrera <alvherre@alvh.no-ip.org>
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>
Date: 2025-03-21T14:39:17Z
Lists: pgsql-hackers
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/
Commits
-
Hide expensive pg_upgrade test behind PG_TEST_EXTRA
- d185161e4739 18.0 landed
- 37fc1803cc12 19 (unreleased) landed
-
Set log_statement=none in t/002_pg_upgrade.pl
- 64fba9c61787 18.0 landed
-
002_pg_upgrade.pl: Move pg_dump test code for better stability
- 8806e4e8deb1 18.0 landed
-
002_pg_upgrade.pl: rename some variables for clarity
- abe56227b2e2 18.0 landed
-
Verify roundtrip dump/restore of regression database
- 172259afb563 18.0 landed
-
Refactor TAP test code for file comparisons into new routine in Utils.pm
- 169208092f5c 18.0 landed
-
Virtual generated columns
- 83ea6c54025b 18.0 cited
-
Put generated_stored test objects in a schema
- 894be11adfa6 18.0 cited
-
Introduce "builtin" collation provider.
- 2d819a08a1cb 17.0 cited
-
Revert "Improve compression and storage support with inheritance"
- 74563f6b9021 17.0 cited