Re: Spread checkpoint sync

Robert Haas wrote:
> Back to your idea: One problem with trying to bound the unflushed data
> is that it's not clear what the bound should be. I've had this mental
> model where we want the OS to write out pages to disk, but that's not
> always true, per Greg Smith's recent posts about Linux kernel tuning
> slowing down VACUUM. A possible advantage of the Momjian algorithm
> (as it's known in the literature) is that we don't actually start
> forcing anything out to disk until we have a reason to do so - namely,
> an impending checkpoint.

My trivial idea was: let's assume we checkpoint every 10 minutes, and
it takes 5 minutes for us to write the data to the kernel. If no one
else is writing to those files, we can safely wait maybe 5 more minutes
before issuing the fsync. If, however, hundreds of writes are coming in
for the same files in those final 5 minutes, we should fsync right away.

My idea is that our delay between writes and fsync should somehow be
controlled by how many writes to the same files are coming to the kernel
while we are considering waiting because the only downside to delay is
the accumulation of non-critical writes coming into the kernel for the
same files we are going to fsync later.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +