From: | Wells Oliver <wells(dot)oliver(at)gmail(dot)com> |
---|---|
To: | Scott Ribe <scott_ribe(at)elevated-dev(dot)com> |
Cc: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, pgsql-admin <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: Faster pg_resore with autovacuum off? |
Date: | 2024-07-28 16:35:41 |
Message-ID: | CAOC+FBV9i9n50JmcJUvtGkPWXcXjgemw==qnufxeca8k6DSQ=Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)elevated-dev(dot)com>
wrote:
> > On Jul 28, 2024, at 6:40 AM, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)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 ;-)
>
>
--
Wells Oliver
wells(dot)oliver(at)gmail(dot)com <wellsoliver(at)gmail(dot)com>
From | Date | Subject | |
---|---|---|---|
Next Message | Wasim Devale | 2024-07-28 17:00:28 | Re: Stream pg_dumpall directly from CentOS7 to Red Hat server |
Previous Message | David G. Johnston | 2024-07-28 16:32:01 | Re: SubTablespaces(Recursive) expected behaviour? |