Optimizing Read-Only Scalability

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Optimizing Read-Only Scalability
Дата
Msg-id 1242320503.3843.562.camel@ebony.2ndQuadrant
обсуждение исходный текст
Ответы Re: Optimizing Read-Only Scalability  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Optimizing Read-Only Scalability  (Josh Berkus <josh@agliodbs.com>)
Список pgsql-hackers
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.

If we think about a situation where write transactions happen
infrequently, then the likelihood is that we end up with xmin==xmax most
of the time.

If our last snapshot had xmin=xmax and the xmax hasn't changed since our
last snapshot then we don't need to scan the procarray at all, just look
at the header.

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.

We don't need to change the API to GetSnapshotData since the snapshot is
statically allocated and unless newly created will contain the "last"
snapshot's data.

Interesting?

-- Simon Riggs           www.2ndQuadrant.comPostgreSQL Training, Services and Support



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: Implementation of GROUPING SETS (T431: Extended grouping capabilities)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Optimizing Read-Only Scalability