On 16/02/2024 06:28, Robert Haas 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.
A variant of this approach:
5. Re-map the shared_buffers when needed.
Between transactions, a backend should not hold any buffer pins. When
there are no pins, you can munmap() the shared_buffers and mmap() it at
a different address.
--
Heikki Linnakangas
Neon (https://neon.tech)
