SQLite is expressly designed to physically verify (“re-read”) every disk-write that occurs.

What you are suggesting would require extra (unnecessary) IO. And if the process were performing more IO, then the CPU usage would be reduced, *not increased*.

(Have you ever considered actually testing one of your theories before posting?)

SQLite is expressly designed to physically verify (“re-read”) every disk-write that occurs

That is wrong and this is the fourth time you've been called out on it (1, 2, 3). You've been touting this "fact" over and over for at least three years. Your claims that SQLite "physically verifies writes" and "re-reads to verify writes" are entirely incorrect, and the "re-reading" claim has been outdated since 2007:

3.12 Releasing The Lock

The last step in the commit process is to release the exclusive lock so that other processes can once again start accessing the database file.

In the diagram at the right, we show that the information that was held in user space is cleared when the lock is released. This used to be literally true for older versions of SQLite. But more recent versions of SQLite keep the user space information in memory in case it might be needed again at the start of the next transaction. It is cheaper to reuse information that is already in local memory than to transfer the information back from the operating system disk cache or to read it off of the disk drive again. Prior to reusing the information in user space, we must first reacquire the shared lock and then we have to check to make sure that no other process modified the database file while we were not holding a lock. There is a counter in the first page of the database that is incremented every time the database file is modified. We can find out if another process has modified the database by checking that counter. If the database was modified, then the user space cache must be cleared and reread. But it is commonly the case that no changes have been made and the user space cache can be reused for a significant performance savings.

7.1 Cache Retained Between Transactions

Step 3.12 of the commit process shows that once the shared lock has been released, all user-space cache images of database content must be discarded. This is done because without a shared lock, other processes are free to modify the database file content and so any user-space image of that content might become obsolete. Consequently, each new transaction would begin by rereading data which had previously been read. This is not as bad as it sounds at first since the data being read is still likely in the operating systems file cache. So the "read" is really just a copy of data from kernel space into user space. But even so, it still takes time.

Beginning with SQLite version 3.3.14 a mechanism has been added to try to reduce the needless rereading of data. ...

(source, emphasis mine - note "The information in this article applies only when SQLite is operating in "rollback mode", or in other words when SQLite is not using a write-ahead log.")

This is not the first time you've made the same "mistake" repeatedly while being corrected. (e.g. 1, 2)

A few more recent references: 1, 2

You have now confirmed that you are a troll. Congratulations on being such an effective one; you've caused a lot of wasted time.

sundialsvc4:

How Do People React to You?
People seem to stop having fun when you show up.

[] True
[] False

Source

Update: Added receiver.