Re: Remove autovacuum GUC?

From: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Remove autovacuum GUC?
Date: 2016-10-20 16:32:24
Message-ID: 59a8da3e-19e5-0a3a-3e2e-609a0bf46f67@commandprompt.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 10/20/2016 09:24 AM, Robert Haas wrote:
> On Thu, Oct 20, 2016 at 11:53 AM, Joshua D. Drake <jd(at)commandprompt(dot)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

That argument suggests we shouldn't have autovacuum :P

> 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.

As mentioned in an other reply, I am not suggesting we can't turn off
autovacuum as a whole. Heck, I even suggested being able to turn it off
per database (versus just per table). I am suggesting that we get rid of
a foot gun for unsophisticated (and thus majority of our users).

>
>> 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.

Those aren't exactly the users we are talking about are we? I also run
into those users all the time.

>
> And I've seen customers solve real production problems by doing
> exactly that, and scheduling vacuums manually. Have I seen people

1 != 10

> 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...".
>

I find it interesting that we are willing to do that every time we add a
feature but once we have that feature it is like pulling teeth to show
the people that implemented those features that some people don't think
it was better :P

Seriously though. I am only speaking from experience from 20 years of
customers. CMD also has customers just like yours but we also run into
lots and lots of people that still do really silly things like we have
already discussed.

Sincerely,

Joshua D. Drake

--
Command Prompt, Inc. http://the.postgres.company/
+1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-10-20 16:49:15 Re: Renaming of pg_xlog and pg_clog
Previous Message Robert Haas 2016-10-20 16:29:47 Re: Renaming of pg_xlog and pg_clog