Feedback-ID: ia2694551:Fastmail
Date: Fri, 21 Mar 2025 19:07:56 +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: <202503211807.hs67n5g4hcvn@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CAExHW5vs-REaZrh=MxHw1f8hjJAaikV209pKQvs3=nnVs49uZQ@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/202503211807.hs67n5g4hcvn%40alvherre.pgsql>
Precedence: bulk

On 2025-Mar-21, Ashutosh Bapat wrote:

> I used the same parallelism in pg_restore and pg_dump too. And your
> numbers seem to be similar to mine; slightly less than 20% slowdown.
> But is that slowdown acceptable? From the earlier discussions, it
> seems the answer is No. Haven't heard otherwise.

I don't think we need to see slowdown this in relative terms, the way we
would discuss a change in the executor.  This is not a change that
would affect user-level stuff in any way.  We need to see it in absolute
terms: in machines similar to mine, the pg_upgrade test would go from
taking 23s to taking 27s.  This is 4s slower, but this isn't an increase
in total test runtime, because decently run test suites run multiple
tests in parallel.  This is the same that Peter said in [1].  The total
test runtime change might not be *that* large.  I'll take a few numbers
and report back.

[1] https://postgr.es/m/b0635739-39f0-4a29-9127-f62aa570a2d8@eisentraut.org

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/
"I love the Postgres community. It's all about doing things _properly_. :-)"
(David Garamond)