From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Speed up Clog Access by increasing CLOG buffers |
Date: | 2016-04-08 07:37:05 |
Message-ID: | CAA4eK1+6oBO4gCyTWGbHwPtS+DSGHU0q347yZhsF8nN+5MadoQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Apr 7, 2016 at 6:48 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> On 2016-04-07 18:40:14 +0530, Amit Kapila wrote:
>
> > This is the data with -b tpcb-like(at)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(at)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(at)1
> -bselect-only(at)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.
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
Attachment | Content-Type | Size |
---|---|---|
test_results_list_300_8GB_group_clog_v8.txt | text/plain | 2.5 KB |
test_results_list_300_8GB_clog_bufs_128.txt | text/plain | 2.5 KB |
test_results_list_300_8GB_content_lock_v1.txt | text/plain | 2.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2016-04-08 07:49:30 | pgsql: Add regression tests for multiple synchronous standbys. |
Previous Message | Etsuro Fujita | 2016-04-08 07:05:37 | Re: Optimization for updating foreign tables in Postgres FDW |