Re: [HACKERS] pg_upgrade vs vacuum_cost_delay
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] pg_upgrade vs vacuum_cost_delay |
Дата | |
Msg-id | ZV7TxiqeMACxjJcf@momjian.us обсуждение исходный текст |
Ответ на | Re: pg_upgrade vs vacuum_cost_delay (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: [HACKERS] pg_upgrade vs vacuum_cost_delay
Re: [HACKERS] pg_upgrade vs vacuum_cost_delay |
Список | 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.
Вложения
В списке pgsql-hackers по дате отправления: