On Wed, Mar 6, 2019 at 11:41 AM Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > I can understand this argument. Is there really a reason to change > those two behaviors separately?
See my previous rely to Andrew, but also, I think you're putting the burden of proof in the wrong place. You could equally well ask "Is there really a reason for work_mem to be different for sorts and index builds? For sorts and hashes? For foreground and background vacuums?" Well, now we've got work_mem, maintenance_work_mem, autovacuum_work_mem, and at least in my experience, that's not necessarily fine-grained enough -- people can't predict whether their maintenance_work_mem setting is OK because they don't know if somebody's going to be running a foreground VACUUM or a CREATE INDEX while it's in flight. See also the bit about hash_mem in https://www.postgresql.org/message-id/CAH2-WzmNwV=LfDRXPsmCqgmm91mp=2b4FvXNF=ccvmrb8yf...@mail.gmail.com -- see also commit a1b395b6a26ae80cde17fdfd2def8d351872f399's introduction of pending_list_cleanup_size, yet another place where we started to decouple something that was inadvisably tied to work_mem. There have been other cases, too, where we've bound unrelated things together into a single parameter, and my feeling is that most of those have turned out a mess. Separate behaviors ought to be controlled by separate settings, even though it means we'll end up with more settings. Two settings each of which does one clear and well-defined thing can even be easier to understand than one setting that does multiple loosely-related things. > The reason I wrote the documentation > weasely is that it seems pointless to have to update it whenever we > implement more things controlled by the same GUC option (which we might, > if we learn new things about how to use COW filesystems later on). > AFAIR Jerry's wording was more precise about what the parameter did. If > the only reason to change those behaviors is to make WAL work better on > COW filesystems, then I don't see the point in splitting the GUC in two, > or documenting in minute detail what it does. Really? What about somebody who has a different experience from Jerry? They turn the parameter on in release N and it's good and then the behavior changes in release N+1 and now it sucks and they read the documentation and it tells them nothing about what has actually changed. They can neither get the behavior back that they liked nor can they understand what behavior they're actually getting that is causing a problem, because it's not documented. I do not think our track record is very good when it comes to deciding which things users "need to know about." Users need to know what's really happening. The idea that we're just going to have a magic flag here that is going to change all of the things that you want changed when you're running on a copy-on-write filesystem and it's all going to work great so that nobody cares about the details does not sound very likely to be correct. We don't even know that the same combination of behavior is performant or safe on every filesystem out there, let alone that future things that come along are going to have similar properties. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
