From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Fsync request queue |
Date: | 2018-04-25 06:19:52 |
Message-ID: | e9a01f61-2ecd-e194-7bbf-d84685122f33@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Nick Dro | 2018-04-25 06:21:25 | Racing DEADLOCK on PostgreSQL 9.3 |
Previous Message | Christophe Pettus | 2018-04-25 05:34:35 | Re: Built-in connection pooling |