On Tue, Sep 23, 2014 at 10:31 AM, Robert Haas <
robertmhaas@gmail.com> wrote:
>
> But this gets at another point: the way we're benchmarking this right
> now, we're really conflating the effects of three different things:
>
> 1. Changing the locking regimen around the freelist and clocksweep.
> 2. Adding a bgreclaimer process.
> 3. Raising the number of buffer locking partitions.
First of all thanks for committing part-1 of this changes and it
seems you are planing to commit part-3 based on results of tests
which Andres is planing to do and for remaining part (part-2), today
I have tried some tests, the results of which are as follows:
Scale Factor - 3000, Shared_buffer - 8GB
| Patch_Ver/Client_Count | 16 | 32 | 64 | 128 |
| reduce-replacement-locking.patch + 128 Buf Partitions | 157732 | 229547 | 271536 | 245295 |
| scalable_buffer_eviction_v9.patch | 163762 | 230753 | 275147 | 248309 |
Scale Factor - 3000, Shared_buffer - 8GB
| Patch_Ver/Client_Count | 16 | 32 | 64 | 128 |
| reduce-replacement-locking.patch + 128 Buf Partitions | 157781 | 212134 | 202209 | 171176 |
| scalable_buffer_eviction_v9.patch | 160301 | 213922 | 208680 | 172720 |
The results indicates that in all cases there is benefit by doing
part-2 (bgreclaimer). Though the benefit at this configuration is
not high, but might be at some higher configurations
(scale factor - 10000) there is more benefit. Do you see any merit
in pursuing further to accomplish part-2 as well?