Re: CPU time for pg_stat_statement
От | Michail Nikolaev |
---|---|
Тема | Re: CPU time for pg_stat_statement |
Дата | |
Msg-id | CANtu0og2w9WSknTH17VnRJ5jDyv9bzSHGCmjRxnBDWcEDnNvKA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: CPU time for pg_stat_statement (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: CPU time for pg_stat_statement
|
Список | pgsql-hackers |
Hello, Tom. > This is a pretty broad claim to make on the basis of one undocumented > test case on one unmentioned platform. I'll try to use pg_stat_kcache to check the difference between Wall and CPU for my case. > On what grounds do you claim getrusage will be better? One thing we > can be pretty certain of is that it will be slower, since it has to > return many more pieces of information. And the API for it only allows > time info to be specified to microseconds, versus nanoseconds for > clock_gettime, so it's also going to be taking a precision hit. My idea was to not replace wall-clock (clock_gettime) by cpu-clock (getrusage). I think about adding getrusage as an additional column (with flag to enable actual measuring). Looks like I need to be more precise in words :) It is just two different clocks - and sometimes you need physical time, sometimes CPU time (and sometimes, for example, amount of WAL written). Best regards, Michail.
В списке pgsql-hackers по дате отправления: