Re: pgBufferUsage.blk_{read|write}_time are zero although there are pgBufferUsage.local_blks_{read|written}
hubert depesz lubaczewski <depesz@depesz.com>
From: hubert depesz lubaczewski <depesz@depesz.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Nazir Bilal Yavuz <byavuz81@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Melanie Plageman <melanieplageman@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2023-10-30T14:14:16Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix description of I/O timing info for shared buffers in EXPLAIN (BUFFERS)
- 8dd70828b460 15.6 landed
- db69101a1d00 16.2 landed
-
pg_stat_statements: Add local_blk_{read|write}_time
- 5147ab1dd34a 17.0 landed
-
Add local_blk_{read|write}_time I/O timing statistics for local blocks
- 295c36c0c1fa 17.0 landed
-
Rename I/O timing statistics columns to shared_blk_{read|write}_time
- 13d00729d422 17.0 landed
-
Count write times when extending relation files for shared buffers
- 2308f18c0733 16.1 landed
- d17ffc734dad 17.0 landed
-
Add JIT deform_counter
- 5a3423ad8ee1 17.0 cited
On Mon, Oct 30, 2023 at 10:45:05AM +0900, Michael Paquier wrote: > On Fri, Oct 27, 2023 at 04:58:20PM +0300, Nazir Bilal Yavuz wrote: > > I think switching it to 'shared' makes sense. That shouldn't confuse > > existing monitoring queries much as the numbers won't change, right? > > Also, if we keep 'shared/local' there could be similar complaints to > > this thread in the future; so, at least adding comments can be > > helpful. > > The problem is that it may impact existing tools that do explain > output deparsing. One of them is https://explain.depesz.com/ that > Hubert Depesz Lubaczewski has implemented, and it would be sad to > break anything related to it. > > I am adding Hubert in CC for comments about changing this > "shared/local" to "shared" on a released branch. Knowing that > "shared" and "local" will need to be handled as separate terms in 17~ > anyway, perhaps that's not a big deal, but let's be sure. Hi, some things will definitely break, but that's 100% OK. The change seems needed, and I can update my parser to deal with it :) Best regards, depesz