On the UI of this patch, you're proposing to add the option FAST. I'm
not a fan of this option name and propose that (if we have it) we use
the name SPREAD instead (defaults to false).
Now we don't actually explain the term "spread" much in the documentation;
we just say "the writes are spread". But it seems more natural to build
on that adjective rather than "fast/slow".
I think starting a spread checkpoint has some usefulness, if your
checkpoint interval is very large but your completion target is not very
close to 1. In that case, you're expressing that you want a checkpoint
to start now and not impact production unduly, so that you know when it
finishes and therefore when is it a good time to start a backup. (You
will still have some WAL to replay, but it won't be as much as if you
just ignored checkpoint considerations completely.)
On the subject of measuring replay times for backups taking while
pgbench is pounding the database, I think a realistic test does *not*
have pgbench running at top speed; rather you have some non-maximal
"-R xyz" option. You would probably determine a value to use by running
without -R, observing what's a typical transaction rate, and using some
fraction (say, half) of that in the real run.