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


Merlin

Fri, 12 Mar 2004 13:30:32 -0500
"Merlin Moncure" <merlin.moncure@rcsonline.com>
Re: Timing of 'SELECT 1'
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, Pennsylvania 19073

Sat, 13 Mar 2004 22:44:26 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Timing of 'SELECT 1'