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
|
Список | 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 по дате отправления: