Re: Remove autovacuum GUC? - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: Remove autovacuum GUC?
Date
Msg-id CAMsr+YGnFSXm7-ZxsTXVwwDwU51PhNp2=VAc_J+FCg-hk8CY5A@mail.gmail.com
Whole thread Raw
In response to Re: Remove autovacuum GUC?  ("Joshua D. Drake" <jd@commandprompt.com>)
Responses Re: Remove autovacuum GUC?  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List pgsql-hackers
<p dir="ltr">On 21 Oct. 2016 12:57 am, "Joshua D. Drake" <<a
href="mailto:jd@commandprompt.com">jd@commandprompt.com</a>>wrote:<br /> ><br /> > Hello,<br /> ><br />
>What about a simpler solution to all of this. Let's just remove it from postgresql.conf. Out of sight. If someone
needsto test they can but a uneducated user won't immediately know what to do about that "autovacuum process" and when
theylook it up the documentation is exceedingly blunt about why to *not* turn it off.<p dir="ltr">Then they'll just do
whatI've seen at multiple sites:  create a cron job that kills it as soon as it starts. Then their DB performance
issuesgo away ... for a while. By the time they're forced to confront it their DB is immensely listed and barely
staggeringalong, or has reached wraparound shutdown. So we get the fun job of trying to fix it using special freeze
toolsetc because they broke the normal ones...<p dir="ltr">We still have fsync=off available. If you want a user foot
gunto crusade against, start there. Even that's useful and legitimate though I wish it were called enable_crash_safety
=off. It's legit to use it in testing, in data ingestion where you'll fsync afterward, in cloud deployments where you
relyon replication and the whole instance gets nuked if it crashes anyway.<p dir="ltr">There are similarly legit
reasonsto turn autovac off but the consequences are less bad.<p dir="ltr">Personally what I think is needed here is to
makemonitoring and bloat visibility not completely suck. So we can warn users if tables haven't been vac'd in ages and
haverecent churn. And so they can easily SELECT a view to get bloat estimates with an estimate of how much drift there
could'vebeen since last vacuum.<p dir="ltr">Users turn off vacuum because they cannot see that it is doing anything
exceptwasting I/O and cpu. So:<p dir="ltr">* A TL;DR in the docs saying what vac does and why not to turn it off. In
particularwarning that turning autovac off will make a slow SB get slower even though it seems to help at first.<p
dir="ltr">*A comment in the conf file with the same TL;DR. Comments are free, let's use a few lines. <p dir="ltr">*
Warnon startup when autovac is off?<p dir="ltr">Personally I wouldn't mind encouraging most users to prefer table or db
levelautovac controls. Though we really need to make them more visible. If that improved I wouldn't really mind
removingthe global autovac option from the conf file though I'd prefer to just give it a decent comment. 

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: FSM corruption leading to errors
Next
From: Michael Paquier
Date:
Subject: Re: Fun fact about autovacuum and orphan temp tables