PostgreSQL direct SSL
PostgreSQL in version 17 introduced sslnegotiation
connection param. Setting it to direct
skips asking the server if it supports SSL connections and proceeds establishing such connection directly.
This post mentions using that to save seconds (!) in connection times, but in a very specific circumstances, where additional factors greatly amplified observed performance. The post itself is interesting on its own. It does not, however, mention how much could be saved with direct
mode in more general case.
So let's do a quick and dirty experiment where sslnegotiation
performance impact will be more realistic. We run both client and server on the same host.
$ multitime -n 1000 -s 0 psql --dbname "postgresql://test:test@localhost?sslmode=verify-ca&sslrootcert=ca.crt&sslnegotiation=postgres" -c "\q"
===> multitime results
1: psql --dbname postgresql://test:test@localhost?sslmode=verify-ca&sslrootcert=ca.crt&sslnegotiation=postgres -c \q
Mean Std.Dev. Min Median Max
real 0.050 0.010 0.030 0.049 0.092
user 0.029 0.008 0.008 0.028 0.059
sys 0.007 0.004 0.000 0.007 0.023
$ multitime -n 1000 -s 0 psql --dbname "postgresql://test:test@localhost?sslmode=verify-ca&sslrootcert=ca.crt&sslnegotiation=direct" -c "\q"
===> multitime results
1: psql --dbname postgresql://test:test@localhost?sslmode=verify-ca&sslrootcert=ca.crt&sslnegotiation=direct -c \q
Mean Std.Dev. Min Median Max
real 0.048 0.010 0.029 0.047 0.100
user 0.029 0.008 0.008 0.028 0.054
sys 0.007 0.004 0.000 0.007 0.027
So a slight difference is visible - here it's on the order of fractions of milliseconds.
Start of psql
itself was probably source of some noise. Also, we stayed on localhost, so had no network latency - connecting to remote host should make those results more in favor of =direct
.