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? -- 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