Re: Speed up pg_checksums in cases where checksum already set

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Speed up pg_checksums in cases where checksum already set
Дата
Msg-id YNrE1mpN0JRIFd/4@paquier.xyz
обсуждение исходный текст
Ответ на Re: Speed up pg_checksums in cases where checksum already set  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Speed up pg_checksums in cases where checksum already set  (Greg Sabino Mullane <htamfids@gmail.com>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: [HACKERS] logical decoding of two-phase transactions
Следующее
От: Dilip Kumar
Дата:
Сообщение: Re: Allow streaming the changes after speculative aborts.