>>> That might be the case in a database with a single small table; i.e.
>>> where all the writes go to a single file. But as soon as you have
>>> large tables (i.e. many segments) or multiple tables, a significant
>>> part of the writes issued independently from checkpointing will be
>>> outside the processing of the individual segment.
>>
>> Statistically, I think that it would reduce the number of unrelated writes
>> taken in a fsync by about half: the last table to be written on a
>> tablespace, at the end of the checkpoint, will have accumulated
>> checkpoint-unrelated writes (bgwriter, whatever) from the whole checkpoint
>> time, while the first table will have avoided most of them.
>
> That's disregarding that a buffer written out by a backend starts to get
> written out by the kernel after ~5-30s, even without a fsync triggering
> it.
I meant my argument with "continuous flushing" activated, so there is no
up to 30 seconds delay induced my the memory manager. Hmmm, maybe I do not
understood your argument.
--
Fabien.
