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.
