On Tue, Oct 24, 2023 at 06:04:13PM +0200, Alvaro Herrera wrote: > Like everybody else, I like having less GUCs to configure, but going > this far to avoid them looks rather disastrous to me. IMO we should > just use Munro's older patches that gave one GUC per SLRU, and users > only need to increase the one that shows up in pg_wait_event sampling. > Someday we will get the (much more complicated) patches to move these > buffers to steal memory from shared buffers, and that'll hopefully let > use get rid of all this complexity.
+1 > On the other hand, here's a somewhat crazy idea. What if, instead of > stealing buffers from shared_buffers (which causes a lot of complexity), > we allocate a common pool for all SLRUs to use? We provide a single > knob -- say, non_relational_buffers=32MB as default -- and we use a LRU > algorithm (or something) to distribute that memory across all the SLRUs. > So the ratio to use for this SLRU or that one would depend on the nature > of the workload: maybe more for multixact in this server here, but more > for subtrans in that server there; it's just the total amount that the > user would have to configure, side by side with shared_buffers (and > perhaps scale with it like wal_buffers), and the LRU would handle the > rest. The "only" problem here is finding a distribution algorithm that > doesn't further degrade performance, of course ... I think it's worth a try. It does seem simpler, and it might allow us to sidestep some concerns about scaling when the SLRU pages are in shared_buffers [0]. [0] https://postgr.es/m/ZPsaEGRvllitxB3v%40tamriel.snowman.net -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
