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.


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to