Re: Fast DSM segments

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fast DSM segments
Date: 2020-04-10 13:55:07
Message-ID: CA+TgmoaqbZrWCoHQ6uvyBfgynQaDR+2Y+x7NUergVwS09mmLPA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Apr 9, 2020 at 1:46 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-04-10 14:07:09 Re: Support for DATETIMEOFFSET
Previous Message Stephen Frost 2020-04-10 13:51:16 Re: where should I stick that backup?