Message-ID: <ff7c4f6961ff733960920107357e2831a00d5b6c.camel@cybertec.at>
Subject: Re: pg_stat_statements, write activity
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Scott Ribe <scott_ribe@elevated-dev.com>, pgsql-admin
	 <pgsql-admin@lists.postgresql.org>
Date: Fri, 16 May 2025 21:37:26 +0200
In-Reply-To: <30BA99F7-F935-4020-B53B-0D70FFA7D205@elevated-dev.com>
References: <30BA99F7-F935-4020-B53B-0D70FFA7D205@elevated-dev.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.56.1 (3.56.1-1.fc42) 
MIME-Version: 1.0
Archived-At: 
 <https://www.postgresql.org/message-id/ff7c4f6961ff733960920107357e2831a00d5b6c.camel%40cybertec.at>
Precedence: bulk

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 che=
ckpoints.
> So then what is shared_blks_written? Or do I misunderstand shared_blks_di=
rtied???

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 n=
ew
blocks.

Yours,
Laurenz Albe