Re: Faster pg_resore with autovacuum off? - Mailing list pgsql-admin

From Wells Oliver
Subject Re: Faster pg_resore with autovacuum off?
Date
Msg-id CAOC+FBV9i9n50JmcJUvtGkPWXcXjgemw==qnufxeca8k6DSQ=Q@mail.gmail.com
Whole thread Raw
In response to Re: Faster pg_resore with autovacuum off?  (Scott Ribe <scott_ribe@elevated-dev.com>)
Responses Re: Faster pg_resore with autovacuum off?
List pgsql-admin
fwiw, we have a lot of materialized views, so restoring a DB on non-vacuumed tables caused the materialization to take a lot longer than it would have with autovacuum running as normal. Seems worth experimenting though.

On Sun, Jul 28, 2024 at 6:58 AM Scott Ribe <scott_ribe@elevated-dev.com> wrote:
> On Jul 28, 2024, at 6:40 AM, Laurenz Albe <laurenz.albe@cybertec.at> wrote:
>
> 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.

Exactly.

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

Good clarification. I personally have never had occasion to move a partial cluster, so my use of "database" in my question was sloppy, I meant "cluster". So yes, I'd delete the cluster and initdb if I ever actually had an OS crash during a pg_restore--which in 20 years of using PG has never happened. I suppose it might matter more if one were forced to run one's db on an unstable platform ;-)



--

pgsql-admin by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: SubTablespaces(Recursive) expected behaviour?
Next
From: Wasim Devale
Date:
Subject: Re: Stream pg_dumpall directly from CentOS7 to Red Hat server