Re: pg_stat_io not tracking smgrwriteback() is confusing
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: pgsql-hackers@postgresql.org, Amit Kapila <amit.kapila16@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, "Jonathan S. Katz" <jkatz@postgresql.org>
Date: 2023-04-24T22:13:00Z
Lists: pgsql-hackers
Hi, On 2023-04-24 17:37:48 -0400, Melanie Plageman wrote: > On Mon, Apr 24, 2023 at 02:14:32PM -0700, Andres Freund wrote: > > It starts blocking once "enough" IO is in flight. For things like an immediate > > checkpoint, that can happen fairly quickly, unless you have a very fast IO > > subsystem. So often it'll not matter whether we track smgrwriteback(), but > > when it matter, it can matter a lot. > > I see. So, it sounds like this is most likely to happen for checkpointer > and not likely to happen for other backends who call > ScheduleBufferTagForWriteback(). It's more likely, but once the IO subsystem is busy, it'll also happen for other users ScheduleBufferTagForWriteback(). > Also, it seems like this (given the current code) is only reachable for > permanent relations (i.e. not for IO object temp relation). If other backend > types than checkpointer may call smgrwriteback(), we likely have to consider > the IO context. I think we should take it into account - it'd e.g. interesting to see a COPY is bottlenecked on smgrwriteback() rather than just writing the data. > I would imagine that we want to smgrwriteback() timing to writes/write time > for the relevant IO context and backend type. Yes. Greetings, Andres Freund
Commits
-
Add writeback to pg_stat_io
- 093e5c57d506 16.0 landed
-
Update parameter name context to wb_context
- 52676dc2e016 16.0 landed
-
Use BUFFER_USAGE_LIMIT to reduce needed test table size
- 322875597c0c 16.0 landed