On Fri, Feb 16, 2024 at 5:29 PM Robert Haas <robertmh...@gmail.com> wrote: > 3. Reserve lots of address space and then only use some of it. I hear > rumors that some forks of PG have implemented something like this. The > idea is that you convince the OS to give you a whole bunch of address > space, but you try to avoid having all of it be backed by physical > memory. If you later want to increase shared_buffers, you then get the > OS to back more of it by physical memory, and if you later want to > decrease shared_buffers, you hopefully have some way of giving the OS > the memory back. As compared with the previous two approaches, this > seems less likely to be noticeable to most PG code. Problems include > (1) you have to somehow figure out how much address space to reserve, > and that forms an upper bound on how big shared_buffers can grow at > runtime and (2) you have to figure out ways to reserve address space > and back more or less of it with physical memory that will work on all > of the platforms that we currently support or might want to support in > the future.
FTR I'm aware of a working experimental prototype along these lines, that will be presented in Vancouver: https://www.pgevents.ca/events/pgconfdev2024/sessions/session/31-enhancing-postgresql-plasticity-new-frontiers-in-memory-management/
