PostgreSQL might benefit from a fd-list fsync() API

Posted Jan 19, 2021 14:55 UTC (Tue) by Wol (subscriber, #4433)
In reply to: PostgreSQL might benefit from a fd-list fsync() API by ringerc
Parent article: Fast commits for ext4

> Note that Pg can't use FS-level write-order barriers after each WAL record written. It'd eliminate the latency after each fsync(), but would be grossly inefficient for this because it'd prevent reordering of non-WAL writes across barriers, and we want the FS to be free to reorder non-WAL writes as aggressively as possible (up to the next checkpoint) in order to do write combining and write deduplication.

Does PG often spend time io-bound? How important really is "as efficient as possible" disk io?

I would have thought this issue would actually impact me even more, given that traditionally Pick has always been "don't bother with caching, it's faster to retrieve it from disk" and Pick can also really hammer the disk.

Cheers,
Wol