No video of the event yet, sorry!

Out of all PostgreSQL configuration parameters that affect performance, shared_buffers is arguably one of the most important. But in order to change its value, the database needs to be restarted, meaning that adjusting shared_buffers in response to a dynamically changing load becomes tricky. You might have strict requirements on high availability that are not allowing a restart, or you want to find the optimal value algorithmically and have to change this configuration very frequently. As a result, users tend to settle down on a non-optimal value and pay the price in performance or in money, getting frustrated either way; even more so in today's elastic computing era. It is also one of the building blocks required to make PostgreSQL truly serverless. The reason is buried deeper in the way shared memory is managed in PostgreSQL and how shared buffers are structured.

PostgreSQL manages all its (lifelong) shared objects in a single memory segment which is provisioned, along with the shared objects, when the server starts. It relies on the memory addresses of these objects being stable while its running. Not only that it expects that the objects be mapped to the same address in every backend that it spawns. These requirements make it impossible to shrink or expand the shared objects by "realloc"ating them.

But the status-quo is about to change. We are working on a patch which would allow resizing the buffer pool without requiring a restart and modernize the way PostgreSQL works with shared memory overall. The trick is making it work without affecting the concurrent load and make "without restart" part of it really useful. This talk will discuss Proposal being discussed on hackers mailing list. The audience will also get an insider view of how a complex feature is developed in PostgreSQL, which is evolving for more than two decades. Though I expect the audience to be mostly the users of PostgreSQL, I am sure they will find this "behind-the-scenes" peek amusing and enlightening.