From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Greg Sabino Mullane <htamfids(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Justin Pryzby <pryzby(at)telsasoft(dot)com> |
Subject: | Re: Speed up pg_checksums in cases where checksum already set |
Date: | 2021-06-29 06:59:34 |
Message-ID: | YNrE1mpN0JRIFd/4@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 | Content-Type | Size |
---|---|---|
004.pg_checksums.optimize.writes.and.always.sync.patch | text/x-diff | 3.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Dilip Kumar | 2021-06-29 07:27:06 | Re: Allow streaming the changes after speculative aborts. |
Previous Message | Amit Kapila | 2021-06-29 06:56:11 | Re: [HACKERS] logical decoding of two-phase transactions |