From: | Melanie Plageman <melanieplageman(at)gmail(dot)com> |
---|---|
To: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
Cc: | byavuz81(at)gmail(dot)com, boekewurm+postgres(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: bgwriter doesn't flush WAL stats |
Date: | 2023-06-22 14:03:41 |
Message-ID: | CAAKRu_YkrtBLR1O__fUim3_A6A_g1uT_FgiMOYwvUjt7R=cJiQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jun 21, 2023 at 9:49 PM Kyotaro Horiguchi
<horikyota(dot)ntt(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-06-22 14:07:12 | Re: Add GUC to tune glibc's malloc implementation. |
Previous Message | Ronan Dunklau | 2023-06-22 14:02:06 | Re: Add GUC to tune glibc's malloc implementation. |