Hi, On 2025-02-27 06:50:41 +0000, Bertrand Drouvot wrote: > On Wed, Feb 26, 2025 at 01:45:39PM -0500, Melanie Plageman wrote: > > Thanks for the continued review! > > > > On Wed, Feb 26, 2025 at 2:41 AM Bertrand Drouvot > > <bertranddrouvot...@gmail.com> wrote: > > > > > > On Wed, Feb 26, 2025 at 01:46:19PM +0900, Fujii Masao wrote: > > > > > > > > With the current patch, when log_connections is enabled, the connection > > > > time is always > > > > captured, and which might introduce performance overhead. No? Some > > > > users who enable > > > > log_connections may not want this extra detail and want to avoid such > > > > overhead. > > > > So, would it make sense to extend log_connections with a new option > > > > like "timing" and > > > > log the connection time only when "timing" is specified? > > > > > > +1, I also think it's a good idea to let users decide if they want the > > > timing > > > measurement overhead (and it's common practice with track_io_timing, > > > track_wal_io_timing, the newly track_cost_delay_timing for example) > > > > It seems to me like the extra timing collected and the one additional > > log message isn't enough overhead to justify its own guc (for now). > > Agree. IIUC, I think that Fujii-san's idea was to extend log_connections with > a new option "timing" (i.e move it from ConfigureNamesBool to say > ConfigureNamesEnum with say on, off and timing?). I think that's a good idea.
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. Greetings, Andres Freund
