Re: Let's make PostgreSQL multi-threaded
От | Andrew Dunstan |
---|---|
Тема | Re: Let's make PostgreSQL multi-threaded |
Дата | |
Msg-id | a31dcb51-83cd-d827-48b7-4d04ebfbd593@dunslane.net обсуждение исходный текст |
Ответ на | Re: Let's make PostgreSQL multi-threaded (Andres Freund <andres@anarazel.de>) |
Список | pgsql-hackers |
On 2023-06-07 We 17:58, Andres Freund wrote:
Hi, On 2023-06-07 08:53:24 -0400, Robert Haas wrote:Now, Andres is not a man who accepts a tax on performance of any size without a fight, so his "really expensive" might turn out to resemble my "pretty cheap." However, if widespread use of TLS is too expensive and we have to start rewriting code to not depend on global variables, that's going to be more of a problem. If we can get by with doing such rewrites only in performance-critical places, it might not still be too bad. Personally, I think the degree of dependence that PostgreSQL has on global variables is pretty excessive and I don't think that a certain amount of refactoring to reduce it would be a bad thing. If it turns into an infinite series of hastily-written patches to rejigger every source file we have, though, then I'm not really on board with that.I think a lot of such rewrites would be a good idea, even if we right now all agree to swear we'll never go to threads. Not having any sort of grouping of global variables makes it IMO considerably harder to debug. I can easily ask somebody to print out a variable pointing to a struct describing the state of a subsystem. I can't really do that for 50 variables. And once you do that, I think you reduce the TLS cost substantially. The variable pointing to the struct is already likely in a register. Whereas each individual variable being in TLS makes the job harder for the compiler.
I could certainly get on board with a project to tame the use of global variables.
cheers
andrew
-- Andrew Dunstan EDB: https://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: