> On Mon, Jul 14, 2025 at 05:55:13PM -0500, Jim Nasby wrote: > > Finally, while shared buffers is the most visible target here, there are > other shared memory settings that have a *much* smaller surface area, and > in my experience are going to be much more valuable from a tuning > perspective; notably wal_buffers and the MXID SLRUs (and possibly CLOG and > subtrans). I say that because unless you're running a workload that > entirely fits in shared buffers, or a *really* small shared buffers > compared to system memory, increasing shared buffers quickly gets into > diminishing returns. But since the default size for the other fixed sized > areas is so much smaller than normal values for shared_buffers, increasing > those areas can have a much, much larger impact on performance. (Especially > for something like the MXID SLRUs.) I would certainly consider focusing on > one of those areas before trying to tackle shared buffers.
That's an interesting idea, thanks for sharing. The reason I'm concentrating on shared buffers is that it was frequently called out as a problem when trying to tune PostgreSQL automatically. In this context shared buffers is usually one of the most impactful knobs, yet one of the most painful to manage as well. But if the amount of complexity around resizable shared buffers will be proved unsurmountable, yeah, it would make sense to consider simpler targets using the same mechanism.
