From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | konstantin knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru> |
Cc: | Craig Ringer <craig(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Logical replication and multimaster |
Date: | 2015-12-09 19:28:24 |
Message-ID: | 20151209192824.GN28762@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2015-12-03 09:54:23 +0300, konstantin knizhnik wrote:
> But right now performance of Multimaster is not limited by logical replication protocol - if I remove DTM and use asynchronous replication (lightweight version of BDR:)
> then I get 38k TPS instead of 12k.
My guess is that that's to a large degree because BDR 'batches' WAL
flushes / fsyncs over several connections. As the data is only applied
in one connection, whereas the primary can use multiple backends, it is
important no to constantly flush, as that's synchronous.
What I did for bdr was to register the 'desired' flush position whenever
replaying a commit (c.f. dlist_push_tail(&bdr_lsn_association,
&flushpos->node); in process_remote_commit()) and whenever feedback is
sent figure out how far the WAL actually has been flushed
(c.f. bdr_get_flush_position()).
Now that cannot trivially be done with 2PC, but it doesn't look all that
hard to change the 2PC API to allow at least some batching of the
fsyncs.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2015-12-09 19:31:35 | Re: Re: Reusing abbreviated keys during second pass of ordered [set] aggregates |
Previous Message | Robert Haas | 2015-12-09 19:19:39 | Re: Logical replication and multimaster |