Re: Too many WAL(s) despite low transaction
От | Selva manickaraja |
---|---|
Тема | Re: Too many WAL(s) despite low transaction |
Дата | |
Msg-id | AANLkTini7zev+CyTLMGFFsaZucxCR35rBsgg_Znj8F-7@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Too many WAL(s) despite low transaction (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: Too many WAL(s) despite low transaction
Re: Too many WAL(s) despite low transaction |
Список | pgsql-admin |
Since the production database is running, I plan to do now is this
1. Set archive_timeout = 20m (Does the change require db restart to take effect?)
2. Set autovacuum=on and track_count=on (Does the change require db restart to take effect?)
Does that mean we are running autovacuum?
3. Run VACUUM FREEZE ANALYZE since bulk loading was done earlier. (Can this be done while the db is active and on production?)
All 3 steps is to lower the WAL files that are being shipped out.
Is this a workable action to achieve the result required?
Please assist.
Thank you.
Regards,
Selvam
1. Set archive_timeout = 20m (Does the change require db restart to take effect?)
2. Set autovacuum=on and track_count=on (Does the change require db restart to take effect?)
Does that mean we are running autovacuum?
3. Run VACUUM FREEZE ANALYZE since bulk loading was done earlier. (Can this be done while the db is active and on production?)
All 3 steps is to lower the WAL files that are being shipped out.
Is this a workable action to achieve the result required?
Please assist.
Thank you.
Regards,
Selvam
В списке pgsql-admin по дате отправления: