>> I am not convinced that it's a good idea to wake up every walsender
>> every time we do XLogInsert(). XLogInsert() is a super-hot code path,
>> and adding more overhead there doesn't seem warranted. We need to
>> replicate commit, commit prepared, etc. quickly, by why do we need to
>> worry about a short delay in replicating heap_insert/update/delete,
>> for example? They don't really matter until the commit arrives. 7
>> seconds might be a bit long, but that could be fixed by decreasing the
>> polling interval for walsender to, say, a second.
> Its not woken up every XLogInsert call. Its only woken up if there was an
> actual disk write + fsync in there. Thats exactly the point of the patch.
Sure, but it's still adding cycles to XLogInsert. I'm not sure that
XLogBackgroundFlush() is the right place to be doing this, but at
least it's in the background rather than the foreground.
> The wakeup rate is actually lower for synchronous_commit=on than before
> because then it unconditionally did a wakeup for every commit (and similar)
> and now only does that if something has been written + fsynced.
I'm a bit confused by this, because surely if there's been a commit,
then WAL has been written and fsync'd, but the reverse is not true.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
