Re: Fast DSM segments

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: Fast DSM segments
Дата
Msg-id CA+hUKGKk-JCwX9y=9YRQ355pds_q0ty9WJLYX6vVtn12pxo3QA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Fast DSM segments  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Fast DSM segments  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Ranier Vilela
Дата:
Сообщение: Re: Speedup usages of pg_*toa() functions
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Fixed the remaining old function names.