On Mon, Jan 26, 2026 at 6:47 PM Anthonin Bonnefoy
<anthonin.bonnefoy@datadoghq.com> wrote:
>
> On Fri, Jan 23, 2026 at 4:50 PM Tom Lane <tgl@sss.pgh.pa.us> 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
