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

From Joshua D. Drake
Subject Re: Remove autovacuum GUC?
Date
Msg-id 59a8da3e-19e5-0a3a-3e2e-609a0bf46f67@commandprompt.com
Whole thread Raw
In response to Re: Remove autovacuum GUC?  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Remove autovacuum GUC?  (Robert Haas <robertmhaas@gmail.com>)
List 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@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

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.



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Renaming of pg_xlog and pg_clog
Next
From: Robert Haas
Date:
Subject: Re: Renaming of pg_xlog and pg_clog