[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-general
Subject:    Re: vacuum is time consuming
From:       Michael Lewis <mlewis () entrata ! com>
Date:       2021-01-28 18:18:26
Message-ID: CAHOFxGrF9JD7BddS1scWP7+cR5HAw4k-6VYwDjxV2xzf2xaMwQ () mail ! gmail ! com
[Download RAW message or body]

Assuming that the system is online and in use, you may want to consider
doing analyze first to ensure stats are proper, and then vacuum all
less-used tables that should be quick then larger/more active tables with
the verbose option to see details of why it might be taking time. If you
are seeing multiple index scan steps, then maintenance_work_mem is lower
than ideal. If you are using default vacuum settings, there is no I/O
throttling as I understand the vacuum_cost_delay and vacuum_cost_limit
settings. What is your concern with it taking time? Depending how you did
the upgrade, there may be no (new/special) need to do the vacuum at all
also.

[Attachment #3 (text/html)]

<div dir="ltr">Assuming that the system  is online and in use, you may want to \
consider doing analyze first to ensure stats are proper, and then vacuum all \
less-used tables that should be quick then larger/more active tables with the verbose \
option to see details of why it might be taking time. If you are seeing multiple \
index scan steps, then  maintenance_work_mem is lower than ideal.  If you are using \
default vacuum settings, there is no I/O throttling as I understand the \
vacuum_cost_delay and vacuum_cost_limit settings. What  is your concern with it \
taking time? Depending how you did the upgrade, there may be no (new/special) need to \
do the vacuum at all also.</div>



[prev in list] [next in list] [prev in thread] [next in thread]