Re: Count and log pages set all-frozen by vacuum

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: Melanie Plageman <melanieplageman(at)gmail(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Count and log pages set all-frozen by vacuum
Date: 2024-10-31 18:12:48
Message-ID: CAD21AoCQLevEZ8oYRA7vGC1WySw4nt4eD2iwwKoJZtwQBbeqOA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Oct 30, 2024 at 2:42 PM Melanie Plageman
<melanieplageman(at)gmail(dot)com> wrote:
>
> Vacuum currently counts and logs the number of pages of a relation
> with newly frozen tuples. It does not count the number of pages newly
> set all-frozen in the visibility map.
>
> The number of pages set all-frozen in the visibility map by a given
> vacuum can be useful when analyzing which normal vacuums reduce the
> number of pages future aggressive vacuum need to scan.

+1

Some small suggestions:

+ vmbits = visibilitymap_set(vacrel->rel, blkno, buf,
+ InvalidXLogRecPtr,
+ vmbuffer, InvalidTransactionId,
+ VISIBILITYMAP_ALL_VISIBLE |
+ VISIBILITYMAP_ALL_FROZEN);

How about using "old_vmbits" or something along the same lines to make
it clear that this value has the bits before visibilitymap_set()?

---
+ /* If it wasn't all-frozen before, count it */
+ if (!(vmbits & VISIBILITYMAP_ALL_FROZEN))

To keep consistent with surrounding codes in lazyvacuum.c, I think we
can write "if ((vmbits & VISIBILITYMAP_ALL_FROZEN) == 0)" instead.

Regards,

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2024-10-31 18:15:36 Re: UUID v7
Previous Message Stepan Neretin 2024-10-31 18:07:00 Re: [PATCH] Improve code coverage of network address functions