On Mon, Jan 26, 2026 at 6:47 PM Anthonin Bonnefoy <[email protected]> wrote: > > On Fri, Jan 23, 2026 at 4:50 PM Tom Lane <[email protected]> wrote: > > Not expressing an opinion on whether we should do this, but > > there is a comment on GetHugePageSize() that you seem to have > > falsified without bothering to correct: > > Thanks for the review, I've updated the comment. > > I've also revised the approach a bit. Using the free huge pages for > auto-tuning was too restrictive, it prevents setup like running > multiple Postgres on the same instance, which would require splitting > the available huge pages. > > I've replaced it with a shared_buffers_autotune_target GUC, which > controls the amount of shared memory to target. If the requested > shared memory is below the target size, shared_buffers will be > increased to (approximately) reach this target. > > By setting shared_buffers_autotune_target to the amount of available > huge pages, shared_buffers will be auto-tuned to use the leftover > space.
The user could achieve the same effect by setting shared_buffers to the same value as shared_buffers_autotune_target. What's the difference? Further they can use -C and -c options to postgres to decide which setting of shared_buffers will consume the desired amount of available memory. That is quite quick and easy. I may be missing some usecase where such runtime autotuning is useful. -- Best Wishes, Ashutosh Bapat
