On 2016-04-07 18:40:14 +0530, Amit Kapila wrote: > On Thu, Apr 7, 2016 at 10:16 AM, Andres Freund <and...@anarazel.de> wrote: > > > > Hi, > > > > On 2016-04-07 09:14:00 +0530, Amit Kapila wrote: > > > On Sat, Apr 2, 2016 at 5:25 PM, Amit Kapila <amit.kapil...@gmail.com> > wrote: > > > I have ran exactly same test on intel x86 m/c and the results are as > below: > > > > Thanks for running these tests! > > > > > Client Count/Patch_ver (tps) 2 128 256 > > > HEAD – Commit 2143f5e1 2832 35001 26756 > > > clog_buf_128 2909 50685 40998 > > > clog_buf_128 +group_update_clog_v8 2981 53043 50779 > > > clog_buf_128 +content_lock 2843 56261 54059 > > > clog_buf_128 +nocontent_lock 2630 56554 54429 > > > > Interesting. > > > > could you perhaps also run a test with -btpcb-like@1 -bselect-only@3?
> This is the data with -b tpcb-like@1 with 20-min run for each version and I > could see almost similar results as the data posted in previous e-mail. > > Client Count/Patch_ver (tps) 256 > clog_buf_128 40617 > clog_buf_128 +group_clog_v8 51137 > clog_buf_128 +content_lock 54188 > > For -b select-only@3, I have done quicktest for each version and number is > same 62K~63K for all version, why do you think this will improve > select-only workload? What I was looking for was pgbench with both -btpcb-like@1 -bselect-only@3 specified; i.e. a mixed read/write test. In my measurement that's where Simon's approach shines (not surprising if you look at the way it works), and it's of immense practical importance - most workloads are mixed. Regards, Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
