Re: [HACKERS] pg_upgrade vs vacuum_cost_delay - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [HACKERS] pg_upgrade vs vacuum_cost_delay
Date
Msg-id ZV7TxiqeMACxjJcf@momjian.us
Whole thread Raw
In response to Re: pg_upgrade vs vacuum_cost_delay  (Magnus Hagander <magnus@hagander.net>)
Responses Re: [HACKERS] pg_upgrade vs vacuum_cost_delay
Re: [HACKERS] pg_upgrade vs vacuum_cost_delay
List pgsql-hackers
On Thu, Jun 16, 2016 at 04:45:14PM +0200, Magnus Hagander wrote:
> On Thu, Jun 16, 2016 at 4:35 PM, Euler Taveira <euler@timbira.com.br> wrote:
> 
>     On 16-06-2016 09:05, Magnus Hagander wrote:
>     > Shouldn't pg_upgrade turn off vacuum cost delay when it vacuums the new
>     > cluster? Not talking about the post-analyze script, but when it runs
>     > vacuumdb to analyze and freeze before loading the new schema, in
>     > prepare_new_cluster()? Those run during downtime, so it seems like you'd
>     > want those to run as fast as possible.
>     >
>     Doesn't --new-options do the job?
> 
> 
> You could, but it seems like it should do it by default. 

Based on this seven year old post, I realized there are minimal
directions in pg_upgrade docs about how to generate statistics quickly,
so I created this patch to help.

We do have docs on updating planner statistics:

    https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-STATISTICS

but that doesn't seem to cover cases where you are doing an upgrade or
pg_dump restore.  Should I move this information into there instead?

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Only you can decide what is important to you.

Attachment

pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: Lockless exit path for ReplicationOriginExitCleanup
Next
From: Bharath Rupireddy
Date:
Subject: Re: Lockless exit path for ReplicationOriginExitCleanup