On 2016-04-11 22:08:15 +0300, Alexander Korotkov wrote: > On Mon, Apr 11, 2016 at 5:04 PM, Alexander Korotkov < > a.korot...@postgrespro.ru> wrote: > > > On Mon, Apr 11, 2016 at 8:10 AM, Andres Freund <and...@anarazel.de> wrote: > > > >> Could you retry after applying the attached series of patches? > >> > > > > Yes, I will try with these patches and snapshot too old reverted. > > > > I've run the same benchmark with 279d86af and 848ef42b reverted. I've > tested of all 3 patches from you applied and, for comparison, 3 patches + > clog buffers reverted back to 32. > > clients patches patches + clog_32 > 1 12594 12556 > 2 26705 26258 > 4 50985 53254 > 8 103234 104416 > 10 135321 130893 > 20 268675 267648 > 30 370437 409710 > 40 486512 482382 > 50 539910 525667 > 60 616401 672230 > 70 667864 660853 > 80 924606 737768 > 90 1217435 799581 > 100 1326054 863066 > 110 1446380 980206 > 120 1484920 1000963 > 130 1512440 1058852 > 140 1536181 1088958 > 150 1504750 1134354 > 160 1461513 1132173 > 170 1453943 1158656 > 180 1426288 1120511 > > I hardly can understand how clog buffers influence read-only > benchmark.
My guess is that the number of buffers influences some alignment; causing a lot of false sharing or something. I.e. the number of clog buffers itself doesn't play a role, it's just a question of how it change the memory layout. > It even harder for me why influence of clog buffers change its > direction after applying your patches. But the results are following. > And I've rechecked some values manually to verify that there is no > error. > I would be very thankful for any explanation. Hm. Possibly this patches influenced alignment, but didn't make things sufficiently stable to guarantee that we're always correctly aligned, thus the 32bit case now regresses. Any chance that I could run some tests on that machine myself? It's very hard to investigate that kind of issue without access; the only thing I otherwise can do is lob patches at you, till we find the relevant memory. If not, one of the things to do is to use perf to compare where cache misses is happening between the fast and the slow case. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
