Robert Haas <robertmh...@gmail.com> wrote: > Kevin Grittner <kevin.gritt...@wicourts.gov> wrote: >> we *really* need to actually get *something* into the docs on >> this, > Sure, I'm not opposed to documenting it. Putting it in the actual > documentation is not a demotion relative to putting a link to it > in the documentation! I didn't figure it was; my emphasis was because this has been raised before and nothing happened for want of a consensus on what particular wording should be used, so users were left with no guidance. I don't want this to continue to be a victim of "the perfect is the enemy of the good" syndrome. >> preferably back-patched. > As for back-patching, we do that regularly with documentation > patches, as the situation seems to warrant. Yeah, I was arguing that this is one of those situations where it is warranted. > Let's add a <note> to that section right after the first > paragraph. OK. >> I actually think that the issue merits space in the docs roughly >> matchnig the Wiki page. Perhaps we could find a place in the >> Server Setup and Operation chapter to more-or-less include the >> current Wiki page contents, and reference *that* from the >> max_connections docs? > > I think the page as it exists today needs some rewriting for tone, > but I think the contents are mostly OK. Would you like to edit the tone in Wiki form? (If the tone is off, I suspect it should be fixed in both places.) > Also, I am a bit doubtful about the advice on sizing the > connection pool as applied to small servers: > surely it's not sane to recommend that a single-processor system > with one disk should have max_connections = 3. At least, *I* > don't think that's sane. I'm not sure it's wrong when combined with this: "Remember that this "sweet spot" is for the number of connections that are actively doing work. ... You should always make max_connections a bit bigger than the number of connections you enable in your connection pool. That way there are always a few slots available for direct connections for system maintenance and monitoring." Where would you expect the knee to be for connections concurrently actively doing work on a single-core, single-drive system ? > At least in HEAD/9.2, I like the idea of adding a section to > Server Setup and Operation to address this. Perhaps something > like "Managing Server Load" or "Preventing Server Overload". I > think there's quite a bit we could say in such a chapter apart > from the stuff on maximum connections, and I think it would be > valuable to have that stuff in our documentation rather than > scattered around the Internet in wiki articles and random Greg > Smith web pages. I'm not sure we want to back-patch an entire new > chapter but let's put something together first and then we'll > figure out what makes sense. As long as we're not drifting (again) into "enemy of the good" territory. Perhaps we should address this issue first, since it is particularly acute, and then add others as separate patches? > A systemic problem with our documentation is that it tells you how > to do X, rather than what you ought to do. This is a good example > of that, but not the only one. We need to be careful of putting > advice in the docs that is one person's opinion rather than an > actual best practice, but I think there is plenty of stuff upon > which enough consensus exists that it really ought to be in the > docs. Like, who really uses REINDEX on a production system, > rather than CREATE INDEX CONCURRENTLY + DROP INDEX? Yet, you > won't find that suggested in our documentation anywhere, AFAIK. Good points. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
