Horton

Re: Log connection establishment timings

Bertrand Drouvot <bertranddrouvot.pg@gmail.com>

View thread View on postgr.es
From: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Melanie Plageman <melanieplageman@gmail.com>, Fujii Masao <masao.fujii@oss.nttdata.com>, Guillaume Lelarge <guillaume@lelarge.info>, Pg Hackers <pgsql-hackers@postgresql.org>, Daniel Gustafsson <daniel@yesql.se>, andrey.chudnovskiy@microsoft.com, Jelte Fennema-Nio <postgres@jeltef.nl>, Jacob Champion <jacob.champion@enterprisedb.com>
Date: 2025-02-28T05:14:17Z
Lists: pgsql-hackers 
Hi,

On Thu, Feb 27, 2025 at 11:14:56AM -0500, Andres Freund wrote:
> I don't think the timing overhead is a relevant factor here - compared to the
> fork of a new connection or performing authentication the cost of taking a few
> timestamps is neglegible. A timestamp costs 10s to 100s of cycles, a fork many
> many millions. Even if you have a really slow timestamp function, it's still
> going to be way way cheaper.

That's a very good point, it has to be put in perspective. The difference in
scale is so significant that the timing collection shouldn't be a concern.
Fair point!

Now I'm thinking what about "if" the connection was on a multi-threaded model?

I think we could reach the same conclusion as thread creation overhead is 
still substantial (allocating stack space, initializing thread state, and other
kernel-level operations) as compare to a really slow timestamp function.

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

Commits

  1. Replace deprecated log_connections values in docs and tests