"Jignesh Shah" <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
