Optimizing Read-Only Scalability
Re: Optimizing Read-Only Scalability
От:
Simon Riggs <simon@2ndQuadrant.com>
Дата:
On Sat, 2009-05-16 at 23:36 -0400, Jignesh K. Shah wrote: > Simon Riggs wrote: > > > >>> So we can optimize away the scan through the procarray by doing two "if" > >>> tests, one outside of the lock, one inside. In normal running, both will > >>> be optimized away, though in read-only periods we would avoid much work. > >>> > >> How much work would it be to work up a test patch? > >> > > > > Not much. The most important thing is a place to test it and access to > > detailed feedback. Let's see if Dimitri does this. > > > > There are some other tuning aspects to be got right first also, but > > those are already known. > > > I would be interested in testing it out.. I have been collecting some > sysbench read-scalability numbers and some other numbers that I can cook > up with dbt3 , igen.. So I have a frame of reference on those numbers .. > I am sure we can always use some extra performance. I've added shared_buffer_partitions = 16..256 plus the GetSnapshotData optimization discussed. I expect the buffer locks to be the dominant problem. Together, they should improve RO scalability at high end. Note this renumbers LWlocks from current value of FirstLockMgrLock onwards, which may skew the Dtrace reports. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support
