Message-ID: <e8a5593d5310ea187aaf213e7a5791127c304308.camel@cybertec.at>
Subject: Re: Faster pg_resore with autovacuum off?
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Scott Ribe <scott_ribe@elevated-dev.com>, pgsql-admin
	 <pgsql-admin@postgresql.org>
Date: Sun, 28 Jul 2024 14:40:32 +0200
In-Reply-To: <154A742E-51A3-4A56-A570-65B9E6A14A4D@elevated-dev.com>
References: 
	<CAOC+FBXP+xQ5fXbqpS-JTKq1D90DSxd+Vzz+UYDF0mfq1bVvRQ@mail.gmail.com>
	 <4ecf57eb54f6d457357e3882c6e9b0e6eb89aa1b.camel@cybertec.at>
	 <CANzqJaC7WgnV74NnLraw_2siNFa6Jkb2d+S7Y9nucAxJpZnaeA@mail.gmail.com>
	 <154A742E-51A3-4A56-A570-65B9E6A14A4D@elevated-dev.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.52.3 (3.52.3-1.fc40) 
MIME-Version: 1.0
Archived-At: 
 <https://www.postgresql.org/message-id/e8a5593d5310ea187aaf213e7a5791127c304308.camel%40cybertec.at>
Precedence: bulk

On Sat, 2024-07-27 at 14:05 -0600, Scott Ribe wrote:
> Similar argument applies to turning off fsync, which I have found to some=
times make a
> significant difference (depending on hardware).

That's bad advice.  Very bad advice.
That is, unless you are ready to delete the cluster and run a new "initdb" =
after an OS crash.

But why risk that, if you can get virtually the same positive effect by dis=
abling
"synchronous_commit".  But all that shouldn't have a big effect on "pg_rest=
ore".
To tune "pg_restore", increate "max_wal_size", "checkpoint_timeout" and "ma=
intenance_work_mem".

> The other argument I've seen, that if there's a crash during restore you'=
ll have a
> corrupted database, is bogus. What are you going to try to do with a data=
base if there's
> a crash during restore???

Drop it?
You are wrong: it is not the database that is broken after a crash, but the=
 entire cluster.

Yours,
Laurenz Albe