On Thu, Jun 20, 2019 at 02:20:27PM -0400, Robert Haas wrote:
> On Tue, Jun 18, 2019 at 9:08 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> > It's currently set to 4, but I now think that was too cautious. It
> > tries to avoid fragmentation by ramping up slowly (that is, memory
> > allocated and in some cases committed by the operating system that we
> > don't turn out to need), but it's pretty wasteful of slots. Perhaps
> > it should be set to 2?
>
> +1. I think I said at the time that I thought that was too cautious...
>
> > Perhaps also the number of slots per backend should be dynamic, so
> > that you have the option to increase it from the current hard-coded
> > value of 2 if you don't want to increase max_connections but find
> > yourself running out of slots (this GUC was a request from Andres but
> > the name was made up by me -- if someone has a better suggestion I'm
> > all ears).
>
> I am not convinced that we really need to GUC-ify this. How about
> just bumping the value up from 2 to say 5? Between the preceding
> change and this one we ought to buy ourselves more than 4x, and if
> that is not enough then we can ask whether raising max_connections is
> a reasonable workaround,
Is there perhaps a way to make raising max_connections not require a
restart? There are plenty of situations out there where restarts
aren't something that can be done on a whim.
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate