On Wed, Oct 15, 2014 at 2:03 AM, Andres Freund <and...@2ndquadrant.com> wrote: > Yes, I can see that now. I do wonder if that's not going to prove quite > expensive... I think I can see some ways around needing that. But I > think that needs some benchmarking first - no need to build a even more > complex solution if not needed.
I did a bit of testing on my MacBook Pro last night. Unfortunately, I don't have access to a large x86 machine the moment.[1] I tried four configurations: (1) master (2) master with chash patch (3) master with chash patch, pg_memory_barrier() changed from lock addl to mfence (4) same as (3), plus barrier at the end of CHashSearch changed to a compiler barrier (which should be safe on x86) I tested pgbench -S, scale factor 100, shared_buffers 400MB. 3 trials per configuration; runs were interleaved. Percentages indicate the average difference between that line and master. At 1 client: (1) 11689.388986 11426.653176 11297.775005 (2) 11618.306822 11331.805396 11273.272945 -0.55% (3) 11813.664402 11300.082928 11231.265030 -0.20% (4) 11428.097384 11266.979165 11294.422376 -1.23% At 16 clients: (1) 56716.465893 56992.590587 56755.298362 (2) 57126.787712 56848.527712 57351.559138 +0.51% (3) 56779.624757 57036.610925 56878.036445 +0.13% (4) 56818.522369 56885.544509 56977.810413 +0.13% I think this tends to confirm that the patch is a small loss (for unknown reasons) at 1 client, but that it picks up speed with more contention, even on a machine with only 4 cores. But if there's an important difference between the different fencing techniques, it doesn't show up in this test. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company [1] Yes, this is a hint. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers