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
