Re: Show WAL write and fsync stats in pg_stat_io
От | Nazir Bilal Yavuz |
---|---|
Тема | Re: Show WAL write and fsync stats in pg_stat_io |
Дата | |
Msg-id | CAN55FZ1AMwGwYBcCB7sP0_aDMYCDggTWhjUxZA9XYMe5ebuuAg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Show WAL write and fsync stats in pg_stat_io (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Show WAL write and fsync stats in pg_stat_io
(Michael Paquier <michael@paquier.xyz>)
Re: Show WAL write and fsync stats in pg_stat_io (Melanie Plageman <melanieplageman@gmail.com>) |
Список | pgsql-hackers |
Hi, On Sun, 31 Dec 2023 at 03:58, Michael Paquier <michael@paquier.xyz> wrote: > > On Tue, Dec 26, 2023 at 03:35:52PM +0300, Nazir Bilal Yavuz wrote: > > On Tue, 26 Dec 2023 at 13:10, Michael Paquier <michael@paquier.xyz> wrote: > >> I am not sure while the whole point of the exercise is to have all the > >> I/O related data in a single view. Something that I've also found a > >> bit disturbing yesterday while looking at your patch is the fact that > >> the operation size is guessed from the context and object type when > >> querying the view because now everything is tied to BLCKSZ. This > >> patch extends it with two more operation sizes, and there are even > >> cases where it may be a variable. Could it be a better option to > >> extend pgstat_count_io_op_time() so as callers can themselves give the > >> size of the operation? > > > > Do you mean removing the op_bytes column and tracking the number of > > bytes in reads, writes, and extends? If so, that makes sense to me but > > I don't want to remove the number of operations; I believe that has a > > value too. We can extend the pgstat_count_io_op_time() so it can both > > track the number of bytes and the number of operations. > > Apologies if my previous wording sounded confusing. The idea I had in > mind was to keep op_bytes in pg_stat_io, and extend it so as a value > of NULL (or 0, or -1) is a synonym as "writes", "extends" and "reads" > as a number of bytes. Oh, I understand it now. Yes, that makes sense. I thought removing op_bytes completely ( as you said "This patch extends it with two more operation sizes, and there are even cases where it may be a variable" ) from pg_stat_io view then adding something like {read | write | extend}_bytes and {read | write | extend}_calls could be better, so that we don't lose any information. > > Also, it is not directly related to this patch but vectored IO [1] is > > coming soon; so the number of operations could be wrong since vectored > > IO could merge a couple of operations. > > Hmm. I have not checked this patch series so I cannot say for sure, > but we'd likely just want to track the number of bytes if a single > operation has a non-equal size rather than registering in pg_stat_io N > rows with different op_bytes, no? Yes, that is correct. > I am looping in Thomas Munro in CC for comments. Thanks for doing that. > > If we want to entirely disable it, we can add > > > > if (MyBackendType == B_WAL_RECEIVER && io_object == IOOBJECT_WAL) > > return; > > > > to the top of the pgstat_count_io_op_time() since all IOOBJECT_WAL > > calls are done by this function, then we can disable it at > > pgstat_tracks_io_bktype(). > > Yeah, a limitation like that may be acceptable for now. Tracking the > WAL writer and WAL sender activities can be relevant in a lot of cases > even if we don't have the full picture for the WAL receiver yet. I added that and disabled B_WAL_RECEIVER backend with comments explaining why. v8 is attached. -- Regards, Nazir Bilal Yavuz Microsoft
Вложения
В списке pgsql-hackers по дате отправления:
Предыдущее
От: "Zhijie Hou (Fujitsu)"Дата:
Сообщение: RE: Synchronizing slots from primary to standby