Re: A few new options for CHECKPOINT - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: A few new options for CHECKPOINT
Date
Msg-id 20201204214634.GA13508@alvherre.pgsql
Whole thread Raw
In response to Re: A few new options for CHECKPOINT  ("Bossart, Nathan" <bossartn@amazon.com>)
Responses Re: A few new options for CHECKPOINT
List pgsql-hackers
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.



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCH] pg_dumpall options proposal/patch
Next
From: Peter Geoghegan
Date:
Subject: Re: POC: Better infrastructure for automated testing of concurrency issues