Re: Fast DSM segments

On Sat, Apr 11, 2020 at 1:55 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> 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.

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