From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Greg Stark <stark(at)mit(dot)edu> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Separating bgwriter and checkpointer |
Date: | 2011-09-20 13:35:59 |
Message-ID: | 4E7896BF.2040209@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 20.09.2011 16:29, Greg Stark wrote:
> On Tue, Sep 20, 2011 at 11:03 AM, Simon Riggs<simon(at)2ndquadrant(dot)com> wrote:
>>> I don't see what difference it makes which process does the I/O. If a
>>> write() by checkpointer process blocks, any write()s by the separate
>>> bgwriter process at that time will block too. If the I/O is not saturated,
>>> and the checkpoint write()s don't block, then even without this patch, the
>>> bgwriter process can handle its usual bgwriter duties during checkpoint just
>>> fine. (And if the I/O is not saturated, it's not an I/O bound system
>>> anyway.)
>>
>> Whatever value you assign to the bgwriter, then this patch makes sure
>> that happens during heavy fsyncs.
>
> I think his point is that it doesn't because if the heavy fsyncs cause
> the system to be i/o bound it then bgwriter will just block issuing
> the writes instead of the fsyncs.
>
> I'm not actually convinced. Writes will only block if the kernel
> decides to block. We don't really know how the kernel makes this
> decision but it's entirely possible that having pending physical i/o
> issued due to an fsync doesn't influence the decision if there is
> still a reasonable number of dirty pages in the buffer cache. In a
> sense, "I/O bound" means different things for write and fsync. Or to
> put it another way fsync is latency sensitive but write is only
> bandwidth sensitive.
Yeah, I was thinking of write()s, not fsyncs. I agree this might have
some effect during fsync phase.
> All that said my question is which way is the code more legible and
> easier to follow?
Hear hear. If we're going to give the bgwriter more responsibilities,
this might make sense even if it has no effect on performance.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2011-09-20 13:49:11 | Re: Separating bgwriter and checkpointer |
Previous Message | Greg Stark | 2011-09-20 13:29:35 | Re: Separating bgwriter and checkpointer |