Re: Speed up Clog Access by increasing CLOG buffers
| От | Amit Kapila |
|---|---|
| Тема | Re: Speed up Clog Access by increasing CLOG buffers |
| Дата | |
| Msg-id | CAA4eK1+6oBO4gCyTWGbHwPtS+DSGHU0q347yZhsF8nN+5MadoQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Speed up Clog Access by increasing CLOG buffers (Andres Freund <andres@anarazel.de>) |
| Ответы |
Re: Speed up Clog Access by increasing CLOG buffers
|
| Список | pgsql-hackers |
On Thu, Apr 7, 2016 at 6:48 PM, Andres Freund <andres@anarazel.de> wrote:
What I was looking for was pgbench with both -btpcb-like@1On 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?
-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.
Вложения
В списке pgsql-hackers по дате отправления: