public inbox for [email protected]
help / color / mirror / Atom feedpg_stat_statements, write activity
6+ messages / 3 participants
[nested] [flat]
* pg_stat_statements, write activity
@ 2025-05-16 17:10 Scott Ribe <[email protected]>
0 siblings, 2 replies; 6+ messages in thread
From: Scott Ribe @ 2025-05-16 17:10 UTC (permalink / raw)
To: pgsql-admin <[email protected]>
I would guess that shared_blks_dirtied in pg_stat_statements is basically the count of blocks which will be logged into WAL and written back during checkpoints. So then what is shared_blks_written? Or do I misunderstand shared_blks_dirtied???
--
Scott Ribe
[email protected]
https://www.linkedin.com/in/scottribe/
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: pg_stat_statements, write activity
@ 2025-05-16 19:25 Achilleas Mantzios <[email protected]>
parent: Scott Ribe <[email protected]>
1 sibling, 0 replies; 6+ messages in thread
From: Achilleas Mantzios @ 2025-05-16 19:25 UTC (permalink / raw)
To: Scott Ribe <[email protected]>; pgsql-admin <[email protected]>
On 16/5/25 20:10, Scott Ribe wrote:
> I would guess that shared_blks_dirtied in pg_stat_statements is basically the count of blocks which will be logged into WAL and written back during checkpoints. So then what is shared_blks_written? Or do I misunderstand shared_blks_dirtied???
My understanding is that dirtied will be eventually written, via
checkpoint or bg writer, so it's a matter of timing.
>
> --
> Scott Ribe
> [email protected]
> https://www.linkedin.com/in/scottribe/
>
>
>
>
>
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: pg_stat_statements, write activity
@ 2025-05-16 19:37 Laurenz Albe <[email protected]>
parent: Scott Ribe <[email protected]>
1 sibling, 1 reply; 6+ messages in thread
From: Laurenz Albe @ 2025-05-16 19:37 UTC (permalink / raw)
To: Scott Ribe <[email protected]>; pgsql-admin <[email protected]>
On Fri, 2025-05-16 at 11:10 -0600, Scott Ribe wrote:
> I would guess that shared_blks_dirtied in pg_stat_statements is basically the
> count of blocks which will be logged into WAL and written back during checkpoints.
> So then what is shared_blks_written? Or do I misunderstand shared_blks_dirtied???
The statistics track how many blocks were dirtied or written by the backend process
that performed the SQL statement. Typically, the backend only dirties the blocks,
but doesn't write them to disk itself. This is done by the checkpointer or the
background writer later on.
Sometimes, a backend writes a block to disk itself. This might happen if a lot
of cache pressure, but usually it happens when the table is extended with new
blocks.
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: pg_stat_statements, write activity
@ 2025-05-17 14:50 Scott Ribe <[email protected]>
parent: Laurenz Albe <[email protected]>
0 siblings, 1 reply; 6+ messages in thread
From: Scott Ribe @ 2025-05-17 14:50 UTC (permalink / raw)
To: Laurenz Albe <[email protected]>; +Cc: pgsql-admin <[email protected]>
> On May 16, 2025, at 1:37 PM, Laurenz Albe <[email protected]> wrote:
>
> Sometimes, a backend writes a block to disk itself. This might happen if a lot
> of cache pressure, but usually it happens when the table is extended with new
> blocks.
Ah, that's the piece I was missing!
Do the written blocks get counted as dirty first, or only as written?
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: pg_stat_statements, write activity
@ 2025-05-19 06:57 Laurenz Albe <[email protected]>
parent: Scott Ribe <[email protected]>
0 siblings, 1 reply; 6+ messages in thread
From: Laurenz Albe @ 2025-05-19 06:57 UTC (permalink / raw)
To: Scott Ribe <[email protected]>; +Cc: pgsql-admin <[email protected]>
On Sat, 2025-05-17 at 08:50 -0600, Scott Ribe wrote:
> > On May 16, 2025, at 1:37 PM, Laurenz Albe <[email protected]> wrote:
> >
> > Sometimes, a backend writes a block to disk itself. This might happen if a lot
> > of cache pressure, but usually it happens when the table is extended with new
> > blocks.
>
> Ah, that's the piece I was missing!
>
> Do the written blocks get counted as dirty first, or only as written?
They will certainly be dirty as well. You can use simple experiments to answer
questions like this:
CREATE TABLE new(id integer);
EXPLAIN (ANALYZE, BUFFERS, COSTS OFF, SUMMARY OFF) INSERT INTO new VALUES (42);
QUERY PLAN
════════════════════════════════════════════════════════════
Insert on new (actual time=0.165..0.166 rows=0.00 loops=1)
Buffers: shared dirtied=1 written=1
-> Result (actual time=0.002..0.003 rows=1.00 loops=1)
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: pg_stat_statements, write activity
@ 2025-05-19 12:34 Scott Ribe <[email protected]>
parent: Laurenz Albe <[email protected]>
0 siblings, 0 replies; 6+ messages in thread
From: Scott Ribe @ 2025-05-19 12:34 UTC (permalink / raw)
To: Laurenz Albe <[email protected]>; +Cc: pgsql-admin <[email protected]>
ooh yeah, I had forgotten those relatively new additions to explain...
^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2025-05-19 12:34 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2025-05-16 17:10 pg_stat_statements, write activity Scott Ribe <[email protected]>
2025-05-16 19:25 ` Achilleas Mantzios <[email protected]>
2025-05-16 19:37 ` Laurenz Albe <[email protected]>
2025-05-17 14:50 ` Scott Ribe <[email protected]>
2025-05-19 06:57 ` Laurenz Albe <[email protected]>
2025-05-19 12:34 ` Scott Ribe <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox