Re: checkpointer continuous flushing - V18

Hallo Andres,

>> AFAICR I used a "flush context" for each table space in some version
>> I submitted, because I do think that this whole writeback logic really
>> does make sense *per table space*, which suggest that there should be as
>> many write backs contexts as table spaces, otherwise the positive effect
>> may going to be totally lost of tables spaces are used. Any thoughts?
>
> Leads to less regular IO, because if your tablespaces are evenly sized
> (somewhat common) you'll sometimes end up issuing sync_file_range's
> shortly after each other. For latency outside checkpoints it's
> important to control the total amount of dirty buffers, and that's
> obviously independent of tablespaces.

I did a quick & small test with random updates on 16 tables with
checkpoint_flush_after=16 checkpoint_timeout=30

(1) with 16 tablespaces (1 per table, but same disk) :
tps = 1100, 27% time under 100 tps

(2) with 1 tablespace :
tps = 1200, 3% time under 100 tps

This result is logical: with one writeback context shared between
tablespaces the sync_file_range is issued on a few buffers per file at a
time on the 16 files, no coalescing occurs there, so this result in random
IOs, while with one table space all writes are aggregated per file.

ISTM that this quick test shows that a writeback context are relevant per
tablespace, as I expected.

--
Fabien.