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.
