Re: Optimizing Read-Only Scalability

Поиск
Список
Период
Сортировка
Искать
От
Simon Riggs
Тема
Re: Optimizing Read-Only Scalability
Дата
в 14:56:55
Msg-id
1242323961.3843.579.camel@ebony.2ndQuadrant
Ответ на
Список
Дерево обсуждения
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 по дате отправления
От: Tom Lane
Дата:
От: Robert Haas
Дата:
FAQ