| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> |
| Cc: | Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com>, Melanie Plageman <melanieplageman(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, "bharath(dot)rupireddyforpostgres(at)gmail(dot)com" <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
| Subject: | Re: Show WAL write and fsync stats in pg_stat_io |
| Date: | 2025-02-04 07:03:55 |
| Message-ID: | Z6G7263rQBDhCyRG@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Feb 03, 2025 at 10:37:54AM +0000, Bertrand Drouvot wrote:
> Based on those results the patch does not show a noticable impact when IO timing
> tracking is/are enabled.
I have spent a good portion of my day doing benchmarking with your
scenarios as much as Nazir's scenarios posted at [1], with
arch_sys_counter as clock source (I am not much into these settings)
on the host I have used. And well, I am not seeing a difference
between the patch and HEAD when enabling the GUC track_io_timing. I
do seem to see a difference when disabling the GUC in the order of
1~2% for the patch and HEAD.
> FYI, It’s also worth noticing that if hpet is set then it also affect negatively
> even if no timing tracking is set. It means that when track IO timing is/are
> enabled the perf regression seen above are not fully related to having then
> enabled but also (for a large part) to hpet vs tsc.
Oh, interesting.
[1]: https://postgr.es/m/CAN55FZ3rb1SPp_17R5nMq+tqLDa0Odb7CxJDsBtW6d4AZo1MGg@mail.gmail.com
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | jian he | 2025-02-04 07:42:28 | Re: Non-text mode for pg_dumpall |
| Previous Message | Amit Kapila | 2025-02-04 06:50:23 | Re: Avoid updating inactive_since for invalid replication slots |