Re: Test to dump and restore objects left behind by regression - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Test to dump and restore objects left behind by regression
Date
Msg-id 202503211807.hs67n5g4hcvn@alvherre.pgsql
Whole thread Raw
In response to Re: Test to dump and restore objects left behind by regression  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
Responses Re: Test to dump and restore objects left behind by regression
List pgsql-hackers
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)



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Support NOT VALID / VALIDATE constraint options for named NOT NULL constraints
Next
From: Matheus Alcantara
Date:
Subject: Re: dblink: Add SCRAM pass-through authentication