Re: [PATCH] Add memory usage reporting to VACUUM VERBOSE

From: Tatsuya Kawata <kawatatatsuya0913(at)gmail(dot)com>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] Add memory usage reporting to VACUUM VERBOSE
Date: 2025-12-21 17:08:42
Message-ID: CAHza6qe7xPgEgb=aN7NBg+kidv7sTQAO+QVWEWhq7t=WR3WM9g@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Sawada-san,

Thank you for your review on the v7 patch!
I have updated the patch based on your feedback.

> IIUC this line aims to add the initial data related to TidStore including
underlying radix tree and the bump context to the total memory usage. I'm
not sure why we do that only when no dead items are collected. If we add
these sizes, should we do that also when the TidStore is reset due to being
full and there are no dead items in the subsequent blocks, no? I guess it
would make more sense to consider adding TidStoreMemoryUsage() also before
cleaning up the TidStore.
You're right and my previous patch is not correct.
I adopted Chao's suggestion from the previous thread.

> I think it's not correct that we say "memory allocated: 64.00MB" in this
case because we don't actually allocate 64MB. Since we're using a TidStore
for dead items storage, we incrementally allocate its space when needed.
I agree. I reverted to your earlier suggested wording "limit was %.2f MB"
which more accurately describes that this is the configured memory limit,
not the actual allocated amount. The updated message format is:
memory usage: 0.02 MB in total, with dead-item storage reset 0 times (limit
was 64.00 MB)

Regards,
Tatsuya Kawata

Attachment Content-Type Size
v8-0001-Add-memory-usage-reporting-to-VACUUM-VERBOSE.patch application/octet-stream 4.4 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2025-12-21 17:55:40 Re: index prefetching
Previous Message Donghang Lin 2025-12-21 16:18:28 Re: bt_index_parent_check and concurrently build indexes