Re: Remove autovacuum GUC?
От | Jim Nasby |
---|---|
Тема | Re: Remove autovacuum GUC? |
Дата | |
Msg-id | 532fbe99-63a3-413a-c052-43ddc154b91c@BlueTreble.com обсуждение исходный текст |
Ответ на | Re: Remove autovacuum GUC? (Craig Ringer <craig.ringer@2ndquadrant.com>) |
Список | 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
В списке pgsql-hackers по дате отправления: