Re: Remove autovacuum GUC?

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: Craig Ringer <craig(dot)ringer(at)2ndquadrant(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
Cc: Peter Geoghegan <pg(at)heroku(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: Remove autovacuum GUC?
Date: 2016-10-21 20:30:39
Message-ID: 532fbe99-63a3-413a-c052-43ddc154b91c@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 10/20/16 11:50 PM, Craig Ringer wrote:
> Personally what I think is needed here is to make monitoring and bloat
> visibility not completely suck. So we can warn users if tables haven't
> been vac'd in ages and have recent churn. And so they can easily SELECT
> a view to get bloat estimates with an estimate of how much drift there
> could've been since last vacuum.

+10. I've seen people spend a bunch of time screwing around with the 2
major "bloat queries", both of which have some issues. And there is *no*
way to actually quantify whether autovac is keeping up with things or not.

> Users turn off vacuum because they cannot see that it is doing anything
> except wasting I/O and cpu. So:
>
> * A TL;DR in the docs saying what vac does and why not to turn it off.
> In particular warning that turning autovac off will make a slow SB get
> slower even though it seems to help at first.

IMHO we should also suggest that for users that have periods of lower
activity that they run a manual vacuum. That reduces the odds of autovac
ruining your day unexpectedly, as well as allowing it to to focus on
high-velocity tables that need more vacuuming and not on huge tables
that just happened to surpass their threshold during a site busy period.

> * A comment in the conf file with the same TL;DR. Comments are free,
> let's use a few lines.
>
> * Warn on startup when autovac is off?

Well, I suspect that someone who thinks autovac=off is a good idea
probably doesn't monitor their logs either, but it wouldn't hurt.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532) mobile: 512-569-9461

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2016-10-21 20:45:38 Re: Proposal for changes to recovery.conf API
Previous Message Jim Nasby 2016-10-21 20:17:11 Re: FSM corruption leading to errors