On Thu, Oct 27, 2016 at 5:14 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: >>> Thanks Tomas and Dilip for doing detailed performance tests for this >>> patch. I would like to summarise the performance testing results. >>> >>> 1. With update intensive workload, we are seeing gains from 23%~192% >>> at client count >=64 with group_update patch .
this is with unlogged table >>> 2. With tpc-b pgbench workload (at 1000 scale factor), we are seeing >>> gains from 12% to ~70% at client count >=64 . Tests are done on >>> 8-socket intel m/c. this is with synchronous_commit=off >>> 3. With pgbench workload (both simple-update and tpc-b at 300 scale >>> factor), we are seeing gain 10% to > 50% at client count >=64 . >>> Tests are done on 8-socket intel m/c. this is with synchronous_commit=off >>> 4. To see why the patch only helps at higher client count, we have >>> done wait event testing for various workloads ,  and the results >>> indicate that at lower clients, the waits are mostly due to >>> transactionid or clientread. At client-counts where contention due to >>> CLOGControlLock is significant, this patch helps a lot to reduce that >>> contention. These tests are done on on 8-socket intel m/c and >>> 4-socket power m/c these both are with synchronous_commit=off + unlogged table >>> 5. With pgbench workload (unlogged tables), we are seeing gains from >>> 15% to > 300% at client count >=72 . >>> >> >> It's not entirely clear which of the above tests were done on unlogged >> tables, and I don't see that in the referenced e-mails. That would be an >> interesting thing to mention in the summary, I think. >> > > One thing is clear that all results are on either > synchronous_commit=off or on unlogged tables. I think Dilip can > answer better which of those are on unlogged and which on > synchronous_commit=off. I have mentioned this above under each of your test point.. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers