| From: | Michail Nikolaev <michail(dot)nikolaev(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: CPU time for pg_stat_statement |
| Date: | 2022-06-08 07:15:19 |
| Message-ID: | CANtu0ojaBhJMxhcOinOcmwuDWUPVaMenZkcLkLVrDDffT2_MqA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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.
In my case I see pretty high correlation of pg_stat_kcache and
pg_stat_statement (clock_gettime vs getrusage).
Looks like CPU usage is hidden somewhere else (planning probably, not
measured on postgres 11, but I see really high
*clauselist_selectivity* in perf).
Thanks,
Michail.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | shiy.fnst@fujitsu.com | 2022-06-08 08:46:46 | Replica Identity check of partition table on subscriber |
| Previous Message | wangw.fnst@fujitsu.com | 2022-06-08 07:12:30 | RE: Perform streaming logical transactions by background workers and parallel apply |