Re: Fix parallel vacuum buffer usage reporting - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: Fix parallel vacuum buffer usage reporting
Date
Msg-id CAD21AoBOkX+QBUqotOS-Cob+9t0pO49+rrpiMcgZfdEsVLA0uw@mail.gmail.com
Whole thread Raw
In response to Fix parallel vacuum buffer usage reporting  (Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>)
Responses Re: Fix parallel vacuum buffer usage reporting
List pgsql-hackers
Hi,

Thank you for the report.

On Fri, Feb 9, 2024 at 6:10 PM Anthonin Bonnefoy
<anthonin.bonnefoy@datadoghq.com> wrote:
>
> Hi,
>
> With a db setup with pgbench, we add an additional index:
> CREATE INDEX ON pgbench_accounts(abalance)
>
> And trigger several updates and vacuum to reach a stable amount of
> dirtied pages:
> UPDATE pgbench_accounts set abalance = abalance + 1 WHERE aid=1; CHECKPOINT;
> VACUUM (VERBOSE, INDEX_CLEANUP ON) pgbench_accounts
>
> The vacuum will report the following:
> INFO:  vacuuming "postgres.public.pgbench_accounts"
> INFO:  launched 1 parallel vacuum worker for index vacuuming (planned: 1)
> INFO:  finished vacuuming "postgres.public.pgbench_accounts": index scans: 1
> ...
> buffer usage: 122 hits, 165 misses, 4 dirtied
>
> 4 pages were reported dirtied. However, we have 5 dirtied blocks at
> the end of the vacuum when looking at pg_buffercache:
>
> SELECT c.relname, b.relfilenode
>                                                          FROM
> pg_buffercache b LEFT JOIN pg_class c
>                                      ON b.relfilenode =
> pg_relation_filenode(c.oid)
>                                WHERE isdirty=true;
>             relname            | relfilenode
> -------------------------------+-------------
>  pg_class                      |        1259
>  pgbench_accounts              |       16400
>  pgbench_accounts              |       16400
>  pgbench_accounts_pkey         |       16408
>  pgbench_accounts_abalance_idx |       16480
>
> The missing dirty block comes from the parallel worker vacuuming the
> abalance index. Running vacuum with parallel disabled will give the
> correct result.
>
> Vacuum uses dedicated VacuumPage{Hit,Miss,Dirty} globals to track
> buffer usage. However, those values are not collected at the end of
> parallel vacuum workers, leading to incorrect buffer count.

True. I think we should fix it also on backbranches.

>
> Those vacuum specific globals are redundant with the existing
> pgBufferUsage and only used in the verbose output. This patch removes
> them and replaces them by pgBufferUsage which is already correctly
> collected at the end of parallel workers, fixing the buffer count.

It seems to make sense to remove VacuumPageHit and friends, only on
the master branch, if we can use BufferUsage instead.

As for the proposed patch, the following part should handle the temp tables too:

                        appendStringInfo(&buf, _("avg read rate: %.3f
MB/s, avg write rate: %.3f MB/s\n"),
                                                         read_rate, write_rate);
                        appendStringInfo(&buf, _("buffer usage: %lld
hits, %lld misses, %lld dirtied\n"),
-                                                        (long long)
AnalyzePageHit,
-                                                        (long long)
AnalyzePageMiss,
-                                                        (long long)
AnalyzePageDirty);
+                                                        (long long)
bufferusage.shared_blks_hit,
+                                                        (long long)
bufferusage.shared_blks_read,
+                                                        (long long)
bufferusage.shared_blks_dirtied);
                        appendStringInfo(&buf, _("system usage: %s"),
pg_rusage_show(&ru0));

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Properly pathify the union planner
Next
From: Ashutosh Bapat
Date:
Subject: Re: DOCS: add helpful partitioning links