On Jul 14, 2011, at 4:42 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > On Thu, Jul 14, 2011 at 9:57 AM, Fujii Masao <masao.fu...@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.
Seems reasonable at first blush, but I worry that changing the algorithm here could change performance in somewhat unpredictable ways. Some of those might be improvements, but I think some careful measurement would be in order. If the primary goal here is to reduce power consumption, another option would be to keep the regular wake-ups most of the time but have some mechanism for putting the process to sleep until wakened when no activity happens for a certain period of time - say, 10 cycles. I'm not at all sure that's better, but it would be less of a change to the existing behavior. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers