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
