Re: bgwriter doesn't flush WAL stats
Melanie Plageman <melanieplageman@gmail.com>
From: Melanie Plageman <melanieplageman@gmail.com>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: byavuz81@gmail.com, boekewurm+postgres@gmail.com, pgsql-hackers@postgresql.org
Date: 2023-06-22T14:03:41Z
Lists: pgsql-hackers
On Wed, Jun 21, 2023 at 9:49 PM Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote: > Regarding the second patch, it introduces WAL IO time as a > IOCONTEXT_NORMAL/IOOBJECT_WAL, but it doesn't seem to follow the > convention or design of the pgstat_io component, which primarily > focuses on shared buffer IOs. I haven't reviewed the patch yet, but in my opinion having an IOOBJECT_WAL makes sense. I imagined that we would add WAL as an IOObject along with others such as an IOOBJECT_BYPASS for "bypass" IO (IO done through the smgr API directly) and an IOOBJECT_SPILL or something like it for spill files from joins/aggregates/etc. > > I do have a question about this. > > So, if we were to start tracking WAL IO would it fit within this > > paradigm to have a new IOPATH_WAL for WAL or would it add a separate > > dimension? Personally, I think WAL fits well as an IOObject. Then we can add IOCONTEXT_INIT and use that for WAL file initialization and IOCONTEXT_NORMAL for normal WAL writes/fysncs/etc. I don't think we need a new dimension for it as it feels like an IO target just like shared buffers and temporary buffers do. I think we should save adding new dimensions for relationships that we can't express in the existing paradigm. - Melanie
Commits
-
Flush WAL stats in bgwriter
- 594001864a36 14.10 landed
- 0684d1949fb4 15.5 landed
- 4a97a43a73cb 16.1 landed
- e64c733bb199 17.0 landed