Re: Tweaking DSM and DSA limits

From: David Fetter <david(at)fetter(dot)org>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Tweaking DSM and DSA limits
Date: 2019-06-20 21:00:34
Message-ID: 20190620210033.GC29683@fetter.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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(dot)munro(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-06-20 21:07:26 Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)
Previous Message Alvaro Herrera 2019-06-20 20:45:05 Re: BUG #15865: ALTER TABLE statements causing "relation already exists" errors when some indexes exist