Re: Let's make PostgreSQL multi-threaded
James Addison <jay@jp-hosting.net>
From: James Addison <jay@jp-hosting.net>
To: Konstantin Knizhnik <knizhnik@garret.ru>
Cc: Pavel Borisov <pashkin.elfe@gmail.com>,
Dilip Kumar <dilipbalaut@gmail.com>, Hannu Krosing <hannuk@google.com>, Heikki Linnakangas <hlinnaka@iki.fi>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2023-06-14T22:23:45Z
Lists: 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?