On Thu, Dec 8, 2016 at 9:07 AM, Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
