To: "Jignesh Shah" <jigneshk@hotmail.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: MemoryContextSwitchTo during table scan? 
In-reply-to: <BAY101-F302023446A2349317A516D0B60@phx.gbl> 
References: <BAY101-F302023446A2349317A516D0B60@phx.gbl>
Comments: In-reply-to "Jignesh Shah" <jigneshk@hotmail.com>
	message dated "Mon, 22 Aug 2005 09:47:38 -0400"
Date: Mon, 22 Aug 2005 11:41:40 -0400
Message-ID: <16259.1124725300@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Jignesh Shah" <jigneshk@hotmail.com> writes:
> Running a script (available on my blog) I find the following top 5 functions 
> where it spends most time during a 10 second run of the script

It's pretty risky to draw conclusions from only 10 seconds' worth of
gprof data --- that's only 1000 samples total at the common sampling
rate of 100/sec.  If there's one function eating 90% of the runtime,
you'll find out, but you don't have enough data to believe that you
know what is happening with resolution of a percent or so.  I generally
try to accumulate several minutes worth of CPU time in a gprof run.

> MemoryContextSwitchTo and LockBuffer itself takes 15% of the total time of 
> the query. I was expecting "read" to be the slowest part (biggest component) 
> but it was way down in the 0.4% level.

You do know that gprof counts only CPU time, and only user-space CPU
time at that?  read() isn't going to show up at all.  It's fairly likely
that your test case is I/O bound and that worrying about CPU efficiency
for it is a waste of time anyway.

			regards, tom lane