Re: checkpointer continuous flushing - V18

[...]

> I had originally kept it with one context per tablespace after 
> refactoring this, but found that it gave worse results in rate limited 
> loads even over only two tablespaces. That's on SSDs though.

Might just mean that a smaller context size is better on SSD, and it could 
still be better per table space.

> The number of pages still in writeback (i.e. for which sync_file_range
> has been issued, but which haven't finished running yet) at the end of
> the checkpoint matters for the latency hit incurred by the fsync()s from
> smgrsync(); at least by my measurement.

I'm not sure I've seen these performance... If you have hard evidence, 
please feel free to share it.

-- 
Fabien.