On 24/04/18 21:00, Andres Freund wrote:
Right now if the queue is full and can't be compacted we end up
fsync()ing on every single write, rather than once per checkpoint
afaict. That's a fairly horrible.
For the case that there's no space in the map, I'd suggest to just do
10% or so of the fsync in the poor sod of a process that finds no
space. That's surely better than constantly fsyncing on every single
write.
Clever idea. In principle, you could do that even with the current
queue, without changing it to a hash table.
Is this a problem in practice, though? I don't remember seeing any
reports of the fsync queue filling up, after we got the code to compact
it. I don't know if anyone has been looking for that, so that might also
explain the absence of reports, though.
The fsync request queue often is fairly large. 20 bytes for each
shared_buffers isn't a neglebible overhead.
Ok, I guess that's a reason to do this, even if the current system works.
- Heikki
