Re: Timing of 'SELECT 1' - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Timing of 'SELECT 1'
Date
Msg-id 200403140344.i2E3iQa27768@candle.pha.pa.us
Whole thread Raw
In response to Re: Timing of 'SELECT 1'  ("Merlin Moncure" <merlin.moncure@rcsonline.com>)
List pgsql-hackers
Merlin Moncure wrote:
> > > The problem with gprof is that I am going to see all the backend
> startup
> > > stuff too, no?  Is there a way to get a dump just the run of the
> query?
> > 
> > I was sort of lurking on this thread, waiting to see what became of
> it.
> > Did
> > nobody actually come to a conclusion on what that "last msec" was
> from?
> 
> I think the consensus was it was coming from the network layer somehow.
> If that's the case (it probably is), there isn't a whole lot that can be
> done about it except to bypass it using server side functions and such.
> 

I did a little more research and found an unusual cause.  It turns out
enabling log_parser/executor_status itself makes SELECT 1's log_duration
go from 0.296 to 1.156 so the slowness I was seeing for SELECT 1 was
from the measurement, not slowness in the normal code path.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: 7.4.2 Build broken on (Sparc) Solaris 7 and 8
Next
From: Bruce Momjian
Date:
Subject: Re: libpq thread safety