Re: [PATCH] Add memory usage reporting to VACUUM VERBOSE - Mailing list pgsql-hackers

From Chao Li
Subject Re: [PATCH] Add memory usage reporting to VACUUM VERBOSE
Date
Msg-id 39071F07-DD5E-4E12-8567-2DD75CB1B25D@gmail.com
Whole thread Raw
In response to Re: [PATCH] Add memory usage reporting to VACUUM VERBOSE  (河田達也 <kawatatatsuya0913@gmail.com>)
List pgsql-hackers
Hi Tatsuya,

I just ran a test against v3.

> On Nov 20, 2025, at 01:30, 河田達也 <kawatatatsuya0913@gmail.com> wrote:
>
>
> I also removed the unintended blank lines and ran pgindent as you suggested.
> I appreciate your continued feedback, and I would be grateful for another review of the v3 patch.
>
> Best regards,
> Tatsuya Kawata
> <v3-0001-Add-memory-usage-reporting-to-VACUUM-VERBOSE.patch>

The test shows:
```
evantest=# VACUUM (VERBOSE) vtest;
INFO:  vacuuming "evantest.public.vtest"
INFO:  finished vacuuming "evantest.public.vtest": index scans: 1
pages: 0 removed, 8621 remain, 8621 scanned (100.00% of total), 0 eagerly scanned
tuples: 250000 removed, 250000 remain, 0 are dead but not yet removable
removable cutoff: 775, which was 0 XIDs old when operation ended
new relfrozenxid: 773, which is 1 XIDs ahead of previous value
frozen: 0 pages from table (0.00% of total) had 0 tuples frozen
visibility map: 8621 pages set all-visible, 0 pages set all-frozen (0 were all-visible)
index scan needed: 8621 pages from table (100.00% of total) had 250000 dead item identifiers removed
index "vtest_pkey": pages: 1374 in total, 0 newly deleted, 0 currently deleted, 0 reusable
avg read rate: 0.000 MB/s, avg write rate: 0.475 MB/s
buffer usage: 27263 hits, 0 reads, 3 dirtied
WAL usage: 18613 records, 3 full page images, 2593581 bytes, 24576 full page image bytes, 0 buffers full
memory usage: total 0.44 MB used across 1 index scan(s) (max 64.00 MB at once)
system usage: CPU: user: 0.04 s, system: 0.00 s, elapsed: 0.04 s
INFO:  vacuuming "evantest.pg_toast.pg_toast_16393"
INFO:  finished vacuuming "evantest.pg_toast.pg_toast_16393": index scans: 0
pages: 0 removed, 0 remain, 0 scanned (100.00% of total), 0 eagerly scanned
tuples: 0 removed, 0 remain, 0 are dead but not yet removable
removable cutoff: 775, which was 0 XIDs old when operation ended
new relfrozenxid: 775, which is 3 XIDs ahead of previous value
frozen: 0 pages from table (100.00% of total) had 0 tuples frozen
visibility map: 0 pages set all-visible, 0 pages set all-frozen (0 were all-visible)
index scan not needed: 0 pages from table (100.00% of total) had 0 dead item identifiers removed
avg read rate: 39.657 MB/s, avg write rate: 0.000 MB/s
buffer usage: 27 hits, 1 reads, 0 dirtied
WAL usage: 1 records, 0 full page images, 258 bytes, 0 full page image bytes, 0 buffers full
memory usage: total 0.00 MB used across 1 index scan(s) (max 64.00 MB at once)
system usage: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s
VACUUM
```

Notice the second “memory usage” line:
```
memory usage: total 0.00 MB used across 1 index scan(s) (max 64.00 MB at once)
```

It says total usage is 0, but max is 64, which is confusing.

I think that is because we initiates as
```
+    /*
+     * Save max_bytes before cleanup, as dead_items_info may be freed in
+     * parallel mode during dead_items_cleanup().
+     */
+    vacrel->dead_items_max_bytes = vacrel->dead_items_info->max_bytes;
```

Where “max_bytes” is "/* the maximum bytes TidStore can use */“, but I think we actually want to show max memories ever
consumedduring vacuuming, right? 

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/







pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: GNU/Hurd portability patches
Next
From: Илья Чердаков
Date:
Subject: Re: Add uuid_to_base32hex() and base32hex_to_uuid() built-in functions