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.
In my case I see pretty high correlation of pg_stat_kcache and
pg_stat_state
Hi,
On Sat, May 21, 2022 at 12:21:49AM +0300, Michail Nikolaev wrote:
>
> > This might be interesting:
> > https://github.com/powa-team/pg_stat_kcache
>
> Oh, nice, looks like it could help me to reduce CPU and test my
> assumption (using exec_user_time and exec_system_time).
>
> BWT, do you know
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 pr
Hello, Thomas.
> This might be interesting:
> https://github.com/powa-team/pg_stat_kcache
Oh, nice, looks like it could help me to reduce CPU and test my
assumption (using exec_user_time and exec_system_time).
BWT, do you know why extension is not in standard contrib (looks mature)?
Best regard
On Sat, May 21, 2022 at 6:50 AM Michail Nikolaev
wrote:
> But what do you think about adding cpu_time (by calling getrusage) to
> pg_stat_statements? Seems it could be very useful for CPU profiling.
>
> I am probably able to prepare the patch, but it is always better to
> get some feedback on the
Michail Nikolaev writes:
> So, looks like clock_gettime is not so accurate to measure real CPU
> usage for some OLTP workloads. I suppose it is caused by the wall time
> vs CPU time difference (IO, thread switch, etc).
This is a pretty broad claim to make on the basis of one undocumented
test cas
Hello, hackers.
Today I was doing some aggregates over pg_stat_statements in order to
find types of queries consuming most of the CPU. Aggregates were made
on two pg_state_statement snapshots within 30 sec delay.
The sum(total_time) had the biggest value for a very frequent query
with about 10ms
