MIME-Version: 1.0
References: <31cc6df9-53fe-3cd9-af5b-ac0d801163f4@iki.fi> <CAMT0RQR+NLJw6hmN88D7RPe=vUEr7DB52dKmS9tWPO_eX2Np0g@mail.gmail.com>
 <CAFiTN-vJqo4TSBpkQTJqhYz6CL0M=cPhQZUXnop1uDC47s2hBg@mail.gmail.com>
In-Reply-To: <CAFiTN-vJqo4TSBpkQTJqhYz6CL0M=cPhQZUXnop1uDC47s2hBg@mail.gmail.com>
From: Pavel Borisov <pashkin.elfe@gmail.com>
Date: Mon, 12 Jun 2023 16:23:14 +0400
Message-ID: <CALT9ZEH_ZT6Fv8KFmEPf2qM7g0Y0mdU-J4PQDVRN+vhn0CLSOQ@mail.gmail.com>
Subject: Re: Let's make PostgreSQL multi-threaded
To: Dilip Kumar <dilipbalaut@gmail.com>
Cc: Hannu Krosing <hannuk@google.com>, Heikki Linnakangas <hlinnaka@iki.fi>, 
	pgsql-hackers <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://www.postgresql.org/message-id/CALT9ZEH_ZT6Fv8KFmEPf2qM7g0Y0mdU-J4PQDVRN%2Bvhn0CLSOQ%40mail.gmail.com>
Precedence: bulk

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