public inbox for [email protected]  
help / color / mirror / Atom feed
pg_stat_statements, write activity
6+ messages / 3 participants
[nested] [flat]

* pg_stat_statements, write activity
@ 2025-05-16 17:10 Scott Ribe <[email protected]>
  2025-05-16 19:25 ` Re: pg_stat_statements, write activity Achilleas Mantzios <[email protected]>
  2025-05-16 19:37 ` Re: pg_stat_statements, write activity Laurenz Albe <[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 17:10 pg_stat_statements, write activity Scott Ribe <[email protected]>
@ 2025-05-16 19:25 ` Achilleas Mantzios <[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 17:10 pg_stat_statements, write activity Scott Ribe <[email protected]>
@ 2025-05-16 19:37 ` Laurenz Albe <[email protected]>
  2025-05-17 14:50   ` Re: pg_stat_statements, write activity 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-16 17:10 pg_stat_statements, write activity Scott Ribe <[email protected]>
  2025-05-16 19:37 ` Re: pg_stat_statements, write activity Laurenz Albe <[email protected]>
@ 2025-05-17 14:50   ` Scott Ribe <[email protected]>
  2025-05-19 06:57     ` Re: pg_stat_statements, write activity 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-16 17:10 pg_stat_statements, write activity Scott Ribe <[email protected]>
  2025-05-16 19:37 ` Re: pg_stat_statements, write activity Laurenz Albe <[email protected]>
  2025-05-17 14:50   ` Re: pg_stat_statements, write activity Scott Ribe <[email protected]>
@ 2025-05-19 06:57     ` Laurenz Albe <[email protected]>
  2025-05-19 12:34       ` Re: pg_stat_statements, write activity 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-16 17:10 pg_stat_statements, write activity Scott Ribe <[email protected]>
  2025-05-16 19:37 ` Re: pg_stat_statements, write activity Laurenz Albe <[email protected]>
  2025-05-17 14:50   ` Re: pg_stat_statements, write activity Scott Ribe <[email protected]>
  2025-05-19 06:57     ` Re: pg_stat_statements, write activity Laurenz Albe <[email protected]>
@ 2025-05-19 12:34       ` Scott Ribe <[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