Re: Speed up pg_checksums in cases where checksum already set - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Speed up pg_checksums in cases where checksum already set
Date
Msg-id YNrE1mpN0JRIFd/4@paquier.xyz
Whole thread Raw
In response to Re: Speed up pg_checksums in cases where checksum already set  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Speed up pg_checksums in cases where checksum already set  (Greg Sabino Mullane <htamfids@gmail.com>)
List pgsql-hackers
On Wed, Jun 23, 2021 at 09:39:37AM +0900, Michael Paquier wrote:
> Perhaps you are right to keep it simple.  If people would like to
> document that more precisely, it could always be changed if
> necessary.  What you have here sounds pretty much right to me.

So, I was looking at this one today, and got confused with the name of
the counters once the patch was in place as this leads to having
things like "blocks" and "total_blocks_modified", which is a bit
confusing as "blocks" stands for the number of blocks scanned,
including new pages.  I have simply suffixed "files" and "blocks" with
"_scanned" to be more consistent with the new counters that are named
"_written", giving the attached.  We still need to have the per-file
counter in scan_file() with the global counters updated at the end of
a file scan for the sake of the file counter, of course.

Does that look fine to you?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: [HACKERS] logical decoding of two-phase transactions
Next
From: Dilip Kumar
Date:
Subject: Re: Allow streaming the changes after speculative aborts.