Re: Let's make PostgreSQL multi-threaded

Поиск
Список
Период
Сортировка
От James Addison
Тема Re: Let's make PostgreSQL multi-threaded
Дата
Msg-id CALDQ5NwfEA+s8O=G-frW6WfRA_yXj_AyhLf2Lb_ZgXWjH3nyEg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Let's make PostgreSQL multi-threaded  (Konstantin Knizhnik <knizhnik@garret.ru>)
Ответы Re: Let's make PostgreSQL multi-threaded  (Konstantin Knizhnik <knizhnik@garret.ru>)
Список pgsql-hackers
On Tue, 13 Jun 2023 at 07:55, Konstantin Knizhnik <knizhnik@garret.ru> wrote:
>
>
>
> On 12.06.2023 3:23 PM, Pavel Borisov wrote:
> > Is the following true or not?
> >
> > 1. If we switch processes to threads but leave the amount of session
> > local variables unchanged, there would be hardly any performance gain.
> > 2. If we move some backend's local variables into shared memory then
> > the performance gain would be very near to what we get with threads
> > having equal amount of session-local variables.
> >
> > In other words, the overall goal in principle is to gain from less
> > memory copying wherever it doesn't add the burden of locks for
> > concurrent variables access?
> >
> > Regards,
> > Pavel Borisov,
> > Supabase
> >
> >
> IMHO both statements are not true.
> Switching to threads will cause less context switch overhead (because
> all threads are sharing the same memory space and so preserve TLB.
> How big will be this advantage? In my prototype I got ~10%. But may be
> it is possible to fin workloads when it is larger.

Hi Konstantin - do you have code/links that you can share for the
prototype and benchmarks used to gather those results?



В списке pgsql-hackers по дате отправления:

Предыдущее
От: James Addison
Дата:
Сообщение: Re: Let's make PostgreSQL multi-threaded
Следующее
От: Nathan Bossart
Дата:
Сообщение: Re: add non-option reordering to in-tree getopt_long