On Thu, Apr 7, 2016 at 6:48 PM, Andres Freund <andres@anarazel.de> wrote:
On 2016-04-07 18:40:14 +0530, Amit Kapila wrote:
> 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.
I have taken the data in the suggested way and the performance seems to be neutral for both the patches. Detailed data for all the runs for three versions is attached.
Median of 3 20-minutes run.
Client Count/Patch_ver (tps)
256
clog_buf_128
110630
clog_buf_128 +group_clog_v8
111575
clog_buf_128 +content_lock
96581
Now, from above data, it appears that content lock patch has some regression, but if you see in detailed data attached with this mail, the highest TPS is close to other patches, but still on the lesser side.
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.
I have tried above tests two times, but didn't notice any gain with content lock approach.
I think by now, we have done many tests with both approaches and we find that in some cases, it is slightly better and in most cases it is neutral and in some cases it is worse than group clog approach. I feel we should go with group clog approach now as that has been tested and reviewed multiple times and in future if we find that other approach is giving substantial gain, then we can anyway change it.