Re: Speed up pg_checksums in cases where checksum already set

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/
Views: Raw Message | Whole Thread | Download mbox | Resend email
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?

Attachment Content-Type Size
004.pg_checksums.optimize.writes.and.always.sync.patch text/x-diff 3.2 KB

In response to


Browse pgsql-hackers by date

  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