Re: Timing overhead and Linux clock sources
От | Bruce Momjian |
---|---|
Тема | Re: Timing overhead and Linux clock sources |
Дата | |
Msg-id | 20120827222031.GA2487@momjian.us обсуждение исходный текст |
Ответ на | Re: Timing overhead and Linux clock sources (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Timing overhead and Linux clock sources
|
Список | pgsql-hackers |
On Mon, Aug 27, 2012 at 04:42:34PM -0400, Robert Haas wrote: > On Mon, Aug 27, 2012 at 1:18 PM, Bruce Momjian <bruce@momjian.us> wrote: > > He wrote it that way to allow for simpler C code --- he could just start > > from 31 and keeping skipping entries until he hit a non-zero. > > > > My format makes it easy to see which line should have the majority of > > the entries, e.g. first line should be > 90%. I doubt there are enough > > people running this cross-version that consistency in output makes any > > difference between major PG versions. > > I don't see why it's better for the first line to have a big number > than the last line. What difference does it make? When you are looking at that output, the <1 usec is where you want to see most of the percentage, and it trails off after that. Here is an example from the current output format: Histogram of timing durations: < usec: count percent 16: 3 0.00007% 8: 563 0.01357% 4: 3241 0.07810% 2: 2990371 72.05956% 1: 1155682 27.84870% That first line is pretty meaningless. You have to look at the last line, see that only 27% of <1, then look up to see that 72% is 1<2, which isn't good. My format shows: < usec % of total count 1 27.84870 1155682 2 72.05956 2990371 4 0.07810 3241 8 0.01357 563 16 0.00007 3 First line, 27%, that's a problem, look down for more details. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-hackers по дате отправления: