On Thu, Oct 20, 2016 at 11:53 AM, Joshua D. Drake <j...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
