Re: MemoryContextSwitchTo during table scan?
От
Tom Lane
Тема
Re: MemoryContextSwitchTo during table scan?
Дата
Msg-id
16259.1124725300@sss.pgh.pa.us
Ответ на
MemoryContextSwitchTo during table scan? (Jignesh Shah)
Список
Дерево обсуждения
MemoryContextSwitchTo during table scan? "Jignesh Shah" <jigneshk@hotmail.com>
Re: MemoryContextSwitchTo during table scan? Tom Lane <tgl@sss.pgh.pa.us>
Re: MemoryContextSwitchTo during table scan? "Jignesh Shah" <jigneshk@hotmail.com>
Re: MemoryContextSwitchTo during table scan? "Luke Lonergan" <llonergan@greenplum.com>
Re: MemoryContextSwitchTo during table scan? Josh Berkus <josh@agliodbs.com>
Re: MemoryContextSwitchTo during table scan? Neil Conway <neilc@samurai.com>
"Jignesh Shah" 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
В списке pgsql-performance по дате отправления