From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Joe Conway <mail(at)joeconway(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PGC_SIGHUP shared_buffers? |
Date: | 2024-02-19 18:13:09 |
Message-ID: | 20240219181309.coz4qvc2wr2v7uhz@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2024-02-19 09:19:16 -0500, Joe Conway wrote:
> On 2/18/24 15:35, Andres Freund wrote:
> > On 2024-02-18 17:06:09 +0530, Robert Haas wrote:
> > > How many people set shared_buffers to something that's not a whole
> > > number of GB these days?
> >
> > I'd say the vast majority of postgres instances in production run with less
> > than 1GB of s_b. Just because numbers wise the majority of instances are
> > running on small VMs and/or many PG instances are running on one larger
> > machine. There are a lot of instances where the total available memory is
> > less than 2GB.
> >
> > > I mean I bet it happens, but in practice if you rounded to the nearest GB,
> > > or even the nearest 2GB, I bet almost nobody would really care. I think it's
> > > fine to be opinionated here and hold the line at a relatively large granule,
> > > even though in theory people could want something else.
> >
> > I don't believe that at all unfortunately.
>
> Couldn't we scale the rounding, e.g. allow small allocations as we do now,
> but above some number always round? E.g. maybe >= 2GB round to the nearest
> 256MB, >= 4GB round to the nearest 512MB, >= 8GB round to the nearest 1GB,
> etc?
That'd make the translation considerably more expensive. Which is important,
given how common an operation this is.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2024-02-19 18:54:01 | Re: PGC_SIGHUP shared_buffers? |
Previous Message | Tomas Vondra | 2024-02-19 17:37:49 | Re: Optimize planner memory consumption for huge arrays |