| From: | Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com> |
|---|---|
| To: | Erik Rijkers <er(at)xs4all(dot)nl>, Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz> |
| Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, pgsql-hackers-owner(at)postgresql(dot)org |
| Subject: | Re: Logical replication existing data copy |
| Date: | 2017-03-24 11:48:35 |
| Message-ID: | 0924a674-ba7b-ee7b-ab3e-4fe6913aa032@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 24/03/17 11:23, Erik Rijkers wrote:
> On 2017-03-24 10:45, Mark Kirkwood wrote:
>>
>> However one minor observation - as Michael Banck noted - the elapsed
>> time for slave to catch up after running:
>>
>> $ pgbench -c8 -T600 bench
>>
>> on the master was (subjectively) much longer than for physical
>> streaming replication. Is this expected?
>>
>
> I think you probably want to do (on the slave) :
>
> alter role <you role> set synchronous_commit = off;
>
> otherwise it's indeed extremely slow.
>
Yes that might be one reason, see
https://www.postgresql.org/message-id/08b7053b-5679-0733-3af7-00b8cde62c90@2ndquadrant.com
(although it probably needs rebase now)
Also don't forget that the snapbuild performance fixes haven't been
committed yet so it can take long time to even start.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Aleksander Alekseev | 2017-03-24 12:17:44 | Re: Re: Declarative partitioning optimization for large amount of partitions |
| Previous Message | Heikki Linnakangas | 2017-03-24 11:36:10 | Re: scram and \password |