On Thu, Nov 23, 2023 at 5:23 AM Bruce Momjian <bruce@momjian.us> wrote:
>
> 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?
Wow, that's... A while :)
I don't think that final sentence really helps much - for anybody who
doesn't know that functionality well already, it will just be
confusing. At the very least it should be a link that sends you to the
documentation of how that functionality works?
But beyond that, perhaps what we'd really want (now that vacuumdb has
gained more functionality, and is used instead of the custom script
all the way) to add is a parameter --no-cost-delay that would issue a
SET to turn it off for the run?
--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/