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

On 07.06.2023 3:53 PM, Robert Haas wrote:
> I think I remember a previous conversation with Andres
> where he opined that thread-local variables are "really expensive"
> (and I apologize in advance if I'm mis-remembering this). 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.

Actually TLS not not more expensive then accessing struct fields (at 
least at x86 platform), consider the following program:

typedef struct {
     int a;
     int b;
     int c;
} ABC;

__thread int a;
__thread int b;
__thread int c;


void use_struct(ABC* abc) {
     abc->a += 1;
     abc->b += 1;
     abc->c += 1;
}

void use_tls(ABC* abc) {
     a += 1;
     b += 1;
     c += 1;
}


Now look at the generated assembler:

use_struct:
     addl    $1, (%rdi)
     addl    $1, 4(%rdi)
     addl    $1, 8(%rdi)
     ret


use_tls:
     addl    $1, %fs:a@tpoff
     addl    $1, %fs:b@tpoff
     addl    $1, %fs:c@tpoff
     ret

> Heikki mentions the idea of having a central Session object and just
> passing that around. I have a hard time believing that's going to work
> out nicely. First, it's not extensible. Right now, if you need a bit
> of additional session-local state, you just declare a variable and
> you're all set. That's not a perfect system and does cause some
> problems, but we can't go from there to a system where it's impossible
> to add session-local state without hacking core. Second, we will be
> sad if session.h ends up #including every other header file that
> defines a data structure anywhere in the backend. Or at least I'll be
> sad. I'm not actually against the idea of having some kind of session
> object that we pass around, but I think it either needs to be limited
> to a relatively small set of well-defined things, or else it needs to
> be design in some kind of extensible way that doesn't require it to
> know the full details of every sort of object that's being used as
> session-local state anywhere in the system. I haven't really seen any
> convincing design ideas around this yet.


There are about 2k static/global variables in Postgres.
It is almost impossible to maintain such struct.
But session context may be still needed for other purposes - if we want 
to support built-in connection pool.

If we are using threads, then all variables needs to be either 
thread-local, either access to them should be synchronized.
But If we want to save session context, then there is no need to 
save/restore all this 2k variables.
We need to capture and these variables which lifetime  exceeds 
transaction boundary.
There are not so much such variables - tens not hundreds.

The question is how to better handle this "session context".
There are two alternatives:
1. Save/restore this context from/to normal TLS variables.
2. Replace such variables with access through the session context struct.

I prefer 2) because it requires less changes in code.
And performance overhead of session context store/resume is negligible 
when number of such variables is ~10.