On Tue, Sep 23, 2014 at 10:31 AM, Robert Haas <robertmh...@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? With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
