Re: Quorum commit for multiple synchronous replication.
От | Michael Paquier |
---|---|
Тема | Re: Quorum commit for multiple synchronous replication. |
Дата | |
Msg-id | CAB7nPqTwDHDDNv6rkCPUg4p03=e4kzU0BN_5KLnnAR8FkmndMw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Quorum commit for multiple synchronous replication. (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Quorum commit for multiple synchronous replication.
|
Список | pgsql-hackers |
On Thu, Dec 8, 2016 at 9:07 AM, Robert Haas <robertmhaas@gmail.com> wrote: > You could do that, but first I would code up the simplest, cleanest > algorithm you can think of and see if it even shows up in a 'perf' > profile. Microbenchmarking is probably overkill here unless a problem > is visible on macrobenchmarks. This is what I would go for! The current code is doing a simple thing: select the Nth element using qsort() after scanning each WAL sender's values. And I think that Sawada-san got it right. Even running on my laptop a pgbench run with 10 sync standbys using a data set that fits into memory, SyncRepGetOldestSyncRecPtr gets at most 0.04% of overhead using perf top on a non-assert, non-debug build. Hash tables and allocations get a far larger share. Using the patch, SyncRepGetSyncRecPtr is at the same level with a quorum set of 10 nodes. Let's kick the ball for now. An extra patch could make things better later on if that's worth it. -- Michael
В списке pgsql-hackers по дате отправления: