On Sat, Jul 17, 2010 at 3:25 AM, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: > On 14/07/10 09:50, Fujii Masao wrote: >> >> TODO >> ---- >> The patch have no features for performance improvement of synchronous >> replication. I admit that currently the performance overhead in the >> master is terrible. We need to address the following TODO items in the >> subsequent CF. >> >> * Change the poll loop in the walsender >> * Change the poll loop in the backend >> * Change the poll loop in the startup process >> * Change the poll loop in the walreceiver > > I was actually hoping to see a patch for these things first, before any of > the synchronous replication stuff. Eliminating the polling loops is > important, latency will be laughable otherwise, and it will help the > synchronous case too.
At first, note that the poll loop in the backend and walreceiver doesn't exist without synchronous replication stuff. Yeah, I'll start with the change of the poll loop in the walsender. I'm thinking that we should make the backend signal the walsender to send the outstanding WAL immediately as the previous synchronous replication patch I submitted in the past year did. I use the signal here because walsender needs to wait for the request from the backend and the ack message from the standby *concurrently* in synchronous replication. If we use the semaphore instead of the signal, the walsender would not be able to respond the ack immediately, which also degrades the performance. The problem of this idea is that signal can be sent per transaction commit. I'm not sure if this frequent signaling really harms the performance of replication. BTW, when I benchmarked the previous synchronous replication patch based on the idea, AFAIR the result showed no impact of the signaling. But... Thought? Do you have another better idea? >> * Perform the WAL write and replication concurrently >> * Send WAL from not only disk but also WAL buffers > > IMHO these are premature optimizations that we should not spend any effort > on now. Maybe later, if ever. Yep! Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
