Re: Fast DSM segments - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Fast DSM segments
Date
Msg-id CA+hUKGKk-JCwX9y=9YRQ355pds_q0ty9WJLYX6vVtn12pxo3QA@mail.gmail.com
Whole thread Raw
In response to Re: Fast DSM segments  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Fast DSM segments
List pgsql-hackers
On Sat, Apr 11, 2020 at 1:55 AM Robert Haas <robertmhaas@gmail.com> wrote:
> 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.

That all makes sense.  Now I'm wondering if I should use exactly that
word in the GUC... dynamic_shared_memory_preallocate?



pgsql-hackers by date:

Previous
From: Ranier Vilela
Date:
Subject: Re: Speedup usages of pg_*toa() functions
Next
From: Peter Eisentraut
Date:
Subject: Re: Fixed the remaining old function names.