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
Re: [HACKERS] Logical replication existing data copy |
Список | 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 по дате отправления: