On Thu, Jul 20, 2017 at 12:51 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Thu, Jul 20, 2017 at 11:09 AM, Claudio Freire <klaussfre...@gmail.com> > wrote: >>> It's no secret that making the ring buffer larger will improve >>> performance -- in fact, not having a ring buffer at all would improve >>> performance even more. But it would also increase the likelihood that >>> the background work of vacuum would impact the performance of >>> foreground operations, which is already a pretty serious problem that >>> we probably don't want to make worse. I'm not certain what the right >>> decision is here, but I think that a careful analysis of possible >>> downsides is needed. >> >> IIRC, originally, the default shared_buffers settings was tiny. > > It is true that we increased the default shared_buffers value from > 32MB to 128MB in f358428280953643313ee7756e0a8b8ccfde7660, but it's > also true ring buffers are capped at 1/8th of shared_buffers > regardless of anything else, so I don't think that's the explanation > here. Even if that weren't the case, how would a 4x increase in the > default size of shared_buffers (which is probably the most-commonly > changed GUC of any that PostgreSQL has) justify a 64x increase in the > size of the ring buffer?
I'm theorizing here, because I've not been involved in any of those decisions. But I have been stracing and checking on vacuum quite frequently lately, so my 2 cents: The 4x increase in shared_buffers acknowledges increases in available host memory over the years. It's not just about how much of shared_buffers is dedicated to the ring buffer, but also whether we can reasonably expect the whole ring to remain in the OS cache while it's getting dirtied. Vacuum will almost always dirty pages once and never again, and flushing dirty pages back to the OS cache ASAP helps avoid a read-modify-write cycle if the page didn't leave the OS cache. That's more likely to happen with smaller rings than with bigger rings. But as memory increases, the ring can be made bigger without fear of it falling from the OS cache prematurely. So, the 64x increase may be justifiable in absolute terms: it's not unlikely that a 16MB buffer will be evicted from the OS cache before vacuum is done with it, even in heavily throttled vacuums. Memory pressure on the host would have to be insane to cause that, in modern systems with GBs of RAM. That might not have been true in the early days. Now, whether autovacuum would suck up a big portion of the shared_buffers or not, is another matter. Perhaps the ring buffer could tune itself to whatever limit seems comfortable in that regard, the way it does with other GUCs (like cost_limit): divide it among the number of workers? -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers