Re: Optimizing Read-Only Scalability
От
Simon Riggs
Тема
Re: Optimizing Read-Only Scalability
Дата
Msg-id
1242323961.3843.579.camel@ebony.2ndQuadrant
Ответ на
Re: Optimizing Read-Only Scalability (Tom Lane)
Список
Дерево обсуждения
Optimizing Read-Only Scalability Simon Riggs <simon@2ndQuadrant.com>
Re: Optimizing Read-Only Scalability Tom Lane <tgl@sss.pgh.pa.us>
Re: Optimizing Read-Only Scalability Simon Riggs <simon@2ndQuadrant.com>
Re: Optimizing Read-Only Scalability Robert Haas <robertmhaas@gmail.com>
Re: Optimizing Read-Only Scalability Tom Lane <tgl@sss.pgh.pa.us>
Re: Optimizing Read-Only Scalability Robert Haas <robertmhaas@gmail.com>
Re: Optimizing Read-Only Scalability Simon Riggs <simon@2ndQuadrant.com>
Re: Optimizing Read-Only Scalability Josh Berkus <josh@agliodbs.com>
Re: Optimizing Read-Only Scalability Simon Riggs <simon@2ndQuadrant.com>
Re: Optimizing Read-Only Scalability "Jignesh K. Shah" <J.K.Shah@Sun.COM>
Re: Optimizing Read-Only Scalability Simon Riggs <simon@2ndQuadrant.com>
On Thu, 2009-05-14 at 13:28 -0400, Tom Lane wrote: > Simon Riggs writes: > > In a thread on -perform it has been observed that our Read-Only > > scalability is not as good as it could be. One problem being that we > > need to scan the whole of the ProcArray to derive a snapshot, which > > becomes the dominant task with many users. > > GetSnapshotData doesn't take an exclusive lock. Neither does start or > end of a read-only transaction. AFAIK there is no reason, and certainly > no shred of experimental evidence, to think that ProcArrayLock > contention is the bottleneck for read-only scenarios. I agree completely; I didn't mention the ProcArrayLock at all... I did mention scanning the procarray itself, which is likely too big to fit in on-chip cache and so must be re-read from main RAM each time. -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
В списке pgsql-hackers по дате отправления