Re: Let's make PostgreSQL multi-threaded - Mailing list pgsql-hackers

From Konstantin Knizhnik
Subject Re: Let's make PostgreSQL multi-threaded
Date
Msg-id 2c2665d2-c513-c12e-9097-9b1805bc2471@garret.ru
Whole thread Raw
In response to Re: Let's make PostgreSQL multi-threaded  (Pavel Borisov <pashkin.elfe@gmail.com>)
Responses Re: Let's make PostgreSQL multi-threaded
Re: Let's make PostgreSQL multi-threaded
List pgsql-hackers

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.

Postgres backend is "thick" not because of large number of local variables.
It is because of local caches: catalog cache, relation cache, prepared 
statements cache,...
If they are not rewritten, then backend still may consume a lot of 
memory even if it will be thread rather then process.
But threads simplify development of global caches, although it can be 
done with DSM.




pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Improve logging when using Huge Pages
Next
From: Gurjeet Singh
Date:
Subject: Re: Document that server will start even if it's unable to open some TCP/IP ports