Re: Tweaking DSM and DSA limits

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Tweaking DSM and DSA limits
Date: 2020-01-31 04:33:18
Message-ID: CA+hUKGJFZFSU8ey13Xu_7krqQS9vse0kdNDKfF6-mR=KLYfmng@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Oct 21, 2019 at 12:21 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> On Fri, Jun 21, 2019 at 6:52 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > On 2019-06-20 14:20:27 -0400, Robert Haas wrote:
> > > I am not convinced that we really need to GUC-ify this. How about
> > > just bumping the value up from 2 to say 5?
> >
> > I'm not sure either. Although it's not great if the only way out for a
> > user hitting this is to increase max_connections... But we should really
> > increase the default.
>
> Ok, hard-to-explain GUC abandoned. Here is a patch that just adjusts
> the two constants. DSM's array allows for 5 slots per connection (up
> from 2), and DSA doubles its size after every two segments (down from
> 4).

Pushed. No back-patch for now: the risk/reward ratio doesn't seem
right for that.

> I have a long wish list of improvements I'd like to investigate in
> this area, subject for future emails, but while I'm making small
> tweaks, here's another small thing: there is no "wait event" while
> allocating (in the kernel sense) POSIX shm on Linux, unlike the
> equivalent IO when file-backed segments are filled with write() calls.
> Let's just reuse the same wait event, so that you can see what's going
> on in pg_stat_activity.

Also pushed.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2020-01-31 04:38:41 Re: table partitioning and access privileges
Previous Message Dominik Czarnota 2020-01-31 03:18:09 PATCH: Fix wrong size argument to pg_strncasecmp