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

From Robert Haas
Subject Re: Remove autovacuum GUC?
Date
Msg-id CA+TgmoaTAadc2qSMT-wsw_Wj=BuX7wfWM1Y02EkRPr_KWePizQ@mail.gmail.com
Whole thread Raw
In response to Re: Remove autovacuum GUC?  ("Joshua D. Drake" <jd@commandprompt.com>)
Responses Re: Remove autovacuum GUC?  (Peter Geoghegan <pg@heroku.com>)
Re: Remove autovacuum GUC?  ("Joshua D. Drake" <jd@commandprompt.com>)
List pgsql-hackers
On Thu, Oct 20, 2016 at 11:53 AM, Joshua D. Drake <jd@commandprompt.com> wrote:
> The right answer isn't the answer founded in the reality for many if not
> most of our users.

I think that's high-handed nonsense.  Sure, there are some
unsophisticated users who do incredibly stupid things and pay the
price for it, but there are many users who are very sophisticated and
make good decisions and don't want or need the system itself to act as
a nanny.  When we constrain the range of possible choices because
somebody might do the wrong thing, sophisticated users are hurt
because they can no longer make meaningful choices, and stupid users
still get in trouble because that's what being stupid does.  The only
way to fix that is to help people be less stupid.  You can't tell
adult users running enterprise-grade software "I'm sorry, Dave, I
can't do that".  Or at least it can cause a few problems.

> I mean that the right answer for -hackers isn't necessarily the right answer
> for users. Testing? Users don't test. They deploy. Education? If most people
> read the docs, CMD and a host of other companies would be out of business.

I've run into these kinds of situations, but I know for a fact that
there are quite a few EnterpriseDB customers who test extremely
thoroughly, read the documentation in depth, and really understand the
system at a very deep level.   I can't say whether the majority of our
customers fall into that category, but we certainly spend a lot of
time working with the ones who do.

> I am not saying I have the right solution but I am saying I think we need a
> *different* solution. Something that limits a *USERS* choice to turn off
> autovacuum. If -hackers need testing or enterprise developers need testing,
> let's account for that but for the user that says this:
>
> My machine/instance bogs down every time autovacuum runs, oh I can turn it
> off....

And I've seen customers solve real production problems by doing
exactly that, and scheduling vacuums manually.  Have I seen people
cause bigger problems than the ones they were trying to solve?  Yes.
Have I recommended something a little less aggressive than completely
shutting autovacuum off as perhaps being a better solution?  Of
course.  But I'm not going to sit here and tell somebody "well, you
know, what you are doing is working whereas the old thing was not
working, but trust me, the way that didn't work was way better...".

> Let's fix *that* problem.

I will say again that I do not think that problem has a technical
solution.  It is a problem of knowledge, not technology.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: Renaming of pg_xlog and pg_clog
Next
From: Peter Geoghegan
Date:
Subject: Re: Remove autovacuum GUC?