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.pg@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
