Message-ID: <11b9f9f053edf5a4909cd7a19ca4cd162ac398f2.camel@moonset.ru>
Subject: Re: Vacuum statistics
From: Andrei Zubkov <zubkov@moonset.ru>
To: Masahiko Sawada <sawada.mshk@gmail.com>, Alena Rybakina
	 <a.rybakina@postgrespro.ru>
Cc: jian he <jian.universality@gmail.com>, Alexander Korotkov
	 <aekorotkov@gmail.com>, Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>, 
	pgsql-hackers <pgsql-hackers@postgresql.org>, a.lepikhov@postgrespro.ru
Date: Fri, 27 Sep 2024 22:25:14 +0300
In-Reply-To: <CAD21AoAVK7DwTZLfhwuRhTGgR=_ASu5YshEg_Cmpojk5ZdZ3tA@mail.gmail.com>
References: <bee34abe-fe87-49b3-8523-8ae19e641ccf@yandex.ru>
	 <ff99283d-f9d4-4b37-b4fa-3a433fb408a4@tantorlabs.com>
	 <e1f5b560691a4fe693625d529e19e13959210568.camel@moonset.ru>
	 <53c47c2d-72a5-44f2-900c-9973b2af1808@tantorlabs.com>
	 <c82e7776-7841-42a0-9247-878584174750@tantorlabs.com>
	 <4a902cea-54fb-41b5-b208-b84731a5f577@postgrespro.ru>
	 <CACJufxHb_YGCp=pVH6DZcpk9yML+SueffPeaRbX2LzXZVahd_w@mail.gmail.com>
	 <CACJufxE6yAP+jUm4_GyKp7gUCkzbuJ9HGB-rR=92_hcLLZ9KTg@mail.gmail.com>
	 <092adec6-4eae-4bd4-bd0d-473a9df1282b@tantorlabs.com>
	 <3deae1bd-ad84-4459-a26e-04c9136b84e9@postgrespro.ru>
	 <CAPpHfdug0s2MD7bBf-5nDQGn1WBxCKiTmZyGfxHz_7P0CDOjbg@mail.gmail.com>
	 <c4e4e305-7119-4183-b49a-d7092f4efba3@postgrespro.ru>
	 <f05a9031-f923-41b1-9bf9-81204cb56561@postgrespro.ru>
	 <CACJufxFU4ej3iGtGg3GDqmGzRmTVq3d9RGq+ibLfQoS8E3hJEQ@mail.gmail.com>
	 <9b10c6d3-52c4-4eef-b67c-c33442667729@postgrespro.ru>
	 <CAD21AoAVK7DwTZLfhwuRhTGgR=_ASu5YshEg_Cmpojk5ZdZ3tA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.46.4-2 
MIME-Version: 1.0
Archived-At: <https://www.postgresql.org/message-id/11b9f9f053edf5a4909cd7a19ca4cd162ac398f2.camel%40moonset.ru>
Precedence: bulk

Hi,

On Fri, 2024-09-27 at 11:15 -0700, Masahiko Sawada wrote:
> I'm concerned that a pg_stat_vacuum_tables view has some duplicated
> statistics that we already collect in different ways. For instance,
> total_blks_{read,hit,dirtied,written} are already tracked at
> system-level by pg_stat_io,

pg_stat_vacuum_tables.total_blks_{read,hit,dirtied,written} tracks
blocks used by vacuum in different ways while vacuuming this particular
table while pg_stat_io tracks blocks used by vacuum on the cluster
level.

> and per-relation block I/O statistics can
> be collected using pg_stat_statements.

This is impossible. pg_stat_statements tracks block statistics on a=20
statement level. One statement could touch many tables and many
indexes, and all used database blocks will be counted by the
pg_stat_statements counters on a statement-level. Autovacuum statistics
won't be accounted by the pg_stat_statements. After all,
pg_stat_statements won't hold the statements statistics forever. Under
pressure of new statements the statement eviction can happen and
statistics will be lost.

All of the above is addressed by relation-level vacuum statistics held
in the Cumulative Statistics System proposed by this patch.
--=20
regards, Andrei Zubkov
Postgres Professional