From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Jignesh Shah" <jigneshk(at)hotmail(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: MemoryContextSwitchTo during table scan? |
Date: | 2005-08-22 15:41:40 |
Message-ID: | 16259.1124725300@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
"Jignesh Shah" <jigneshk(at)hotmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2005-08-22 17:18:28 | Re: Finding bottleneck |
Previous Message | William Yu | 2005-08-22 15:07:36 | Re: extremly low memory usage |