Re: Logical replication existing data copy

From: Erik Rijkers <er(at)xs4all(dot)nl>
To: Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>
Cc: Peter Eisentraut <peter(dot)eisentraut(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-02-28 06:38:46
Message-ID: fd04d14826ca856494a9e9717b1f26e6@xs4all.nl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2017-02-27 15:08, Petr Jelinek wrote:
>
> The performance was why in original patch I wanted the apply process to
> default to synchronous_commit = off as without it the apply performance
> (due to applying transactions individually and in sequences) is quite
> lackluster.
>
> It can be worked around using user that has synchronous_commit = off
> set
> via ALTER ROLE as owner of the subscription.
>

Wow, that's a huge difference in speed.

I set
ALTER ROLE aardvark synchronous_commit = off;

during the first iteration of a 10x pgbench-test (so the first was still
done with it 'on'):
here the pertinent grep | uniq -c lines:

-- out_20170228_0004.txt
10 -- pgbench -c 16 -j 8 -T 900 -P 180 -n -- scale 25
10 -- All is well.
1 -- 1325 seconds total.
9 -- 5 seconds total.

And that 5 seconds is a hardcoded wait; so it's probably even quicker.

This is a slowish machine but that's a really spectacular difference.
It's the difference between keeping up or getting lost.

Would you remind me why synchronous_commit = on was deemed a better
default? This thread isn't very clear about it (not the 'logical
replication WIP' thread).

thanks,

Erik Rijkers

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavan Deolasee 2017-02-28 06:49:50 Re: Patch: Write Amplification Reduction Method (WARM)
Previous Message Michael Paquier 2017-02-28 06:28:27 Re: timeouts in PostgresNode::psql