Re: Fast DSM segments - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Fast DSM segments
Date
Msg-id CA+TgmoaqbZrWCoHQ6uvyBfgynQaDR+2Y+x7NUergVwS09mmLPA@mail.gmail.com
Whole thread Raw
In response to Fast DSM segments  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: Fast DSM segments  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-hackers
On Thu, Apr 9, 2020 at 1:46 AM Thomas Munro <thomas.munro@gmail.com> wrote:
> The attached highly experimental patch adds a new GUC
> dynamic_shared_memory_main_size.  If you set it > 0, it creates a
> fixed sized shared memory region that supplies memory for "fast" DSM
> segments.  When there isn't enough free space, dsm_create() falls back
> to the traditional approach using eg shm_open().

I think this is a reasonable option to have available for people who
want to use it. I didn't want to have parallel query be limited to a
fixed-size amount of shared memory because I think there are some
cases where efficient performance really requires a large chunk of
memory, and it seemed impractical to keep the largest amount of memory
that any query might need to use permanently allocated, let alone that
amount multiplied by the maximum possible number of parallel queries
that could be running at the same time. But none of that is any
argument against giving people the option to preallocate some memory
for parallel query.

My guess is that on smaller boxes this won't find a lot of use, but on
bigger ones it will be handy. It's hard to imagine setting aside 1GB
of memory for this if you only have 8GB total, but if you have 512GB
total, it's pretty easy to imagine.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: where should I stick that backup?
Next
From: Tom Lane
Date:
Subject: Re: Support for DATETIMEOFFSET