Re: [HACKERS] Logical replication existing data copy

Поиск
Список
Период
Сортировка
От Erik Rijkers
Тема Re: [HACKERS] Logical replication existing data copy
Дата
Msg-id fd04d14826ca856494a9e9717b1f26e6@xs4all.nl
обсуждение исходный текст
Ответ на Re: [HACKERS] Logical replication existing data copy  (Petr Jelinek <petr.jelinek@2ndquadrant.com>)
Ответы Re: [HACKERS] Logical replication existing data copy  (Erik Rijkers <er@xs4all.nl>)
Re: [HACKERS] Logical replication existing data copy  (Robert Haas <robertmhaas@gmail.com>)
Список 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 --
1325seconds 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] timeouts in PostgresNode::psql
Следующее
От: Pavan Deolasee
Дата:
Сообщение: Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)