You signed in with another tab or window.Reload to refresh your session.You signed out in another tab or window.Reload to refresh your session.You switched accounts on another tab or window.Reload to refresh your session.Dismiss alert
This commit is a rework of2421e9a, about which Andres Freund hasraised some concerns as it is valuable to have both track_io_timing andtrack_wal_io_timing in some cases, as the WAL write and fsync paths canbe a major bottleneck for some workloads. Hence, it can be relevant tonot calculate the WAL timings in environments where pg_test_timingperforms poorly while capturing some IO data under track_io_timing forthe non-WAL IO paths. The opposite can be also true: it should bepossible to disable the non-WAL timings and enable the WAL timings (theprevious GUC setups allowed this possibility).track_wal_io_timing is added back in this commit, controlling if WALtimings should be calculated in pg_stat_io for the read, fsync and writepaths, as done previously with pg_stat_wal. pg_stat_wal previouslytracked only the sync and write parts (now removed), read stats is newdata tracked in pg_stat_io, all three are aggregated iftrack_wal_io_timing is enabled. The read part matters during recoveryor if a XLogReader is used.Extra note: more control over if the types of timings calculated inpg_stat_io could be done with a GUC that lists pairs of (IOObject,IOOp).Reported-by: Andres Freund <andres@anarazel.de>Author: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>Co-authored-by: Michael Paquier <michael@paquier.xyz>Discussion:https://postgr.es/m/3opf2wh2oljco6ldyqf7ukabw3jijnnhno6fjb4mlu6civ5h24@fcwmhsgmlmzu