On Thu, Jul 14, 2011 at 10:53 AM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> On 14.07.2011 12:42, Simon Riggs wrote:
>>
>> On Thu, Jul 14, 2011 at 9:57 AM, Fujii Masao<masao.fujii@gmail.com>
>> wrote:
>>
>>> Currently walwriter might write out the WAL before a transaction commits.
>>> IOW, walwriter tries to write out the WAL in wal_buffers in every
>>> wakeups.
>>> This might be useful for long transaction which generates lots of WAL
>>> records before commit. So we should call SetLatch() in XLogInsert()
>>> instead
>>> of RecordTransactionCommit()? Though I'm not sure how much walwriter
>>> improves the performance of synchronous commit case..
>>
>> Yeh, we did previously have a heuristic to write out the WAL when it
>> was more than half full. Not sure I want to put exactly that code back
>> into such a busy code path.
>>
>> I suggest that we set latch every time the wal buffers wrap.
>>
>> So at the bottom of AdvanceXLInsertBuffer(), if nextidx == 0 then
>> SetLatch on the WALWriter.
>>
>> That's a simple test and we only check it if we're switch WAL buffer page.
>
> That was my first though too - but I wonder if that's too aggressive? A
> backend that does for example a large bulk load will cycle through the
> buffers real quick. It seems like a bad idea to wake up walwriter between
> each buffer in that case. Then again, setting a latch that's already set is
> cheap, so maybe it works fine in practice.
>
> Maybe it would be better to do it less frequently, say, every time you
> switch to new WAL segment. Or every 10 buffers or something like that.
Yes, that roughly what I'm saying. When nextidx == 0 is just after we
wrapped wal_buffers, i.e. we only wake up the WALWriter every
wal_buffers pages.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
