Re: Page-at-a-time Locking Considerations

Поиск
Список
Период
Сортировка
От Gregory Stark
Тема Re: Page-at-a-time Locking Considerations
Дата
Msg-id 87odaw5w1y.fsf@oxford.xeocode.com
обсуждение исходный текст
Ответ на Re: Page-at-a-time Locking Considerations  (Simon Riggs <simon@2ndquadrant.com>)
Ответы Re: Page-at-a-time Locking Considerations  (Alvaro Herrera <alvherre@commandprompt.com>)
Re: Page-at-a-time Locking Considerations  (Simon Riggs <simon@2ndquadrant.com>)
Re: Page-at-a-time Locking Considerations  (Zdenek Kotala <Zdenek.Kotala@Sun.COM>)
Список pgsql-hackers
"Simon Riggs" <simon@2ndquadrant.com> writes:

> We still have a higher than desirable variability in response times and
> I'm looking at possible causes.

I agree we have a problem with this. My feeling is that the problems have more
to do with higher level things like stats being toasted, or checkpoints or wal
file changes, or a myriad of other things. But clog lru thrashing while
holding other locks is a definite possibility too.

I wonder how hard it would be to shove the clog into regular shared memory
pages and let the clock sweep take care of adjusting the percentage of shared
mem allocated to the clog versus data pages.

> I'll try patching it, unless you can think of a reason why its a
> complete non-starter? I'm not saying we'd want it yet, just that it
> seems worth trying.

Sure, but a good experiment needs af theory to test. I think you have to find
a way to measure this first. Otherwise you're going to write a patch and then
have two trees and be searching around in the dark for a difference.

This strikes me as something dtrace might be able to help measure.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services!


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

Предыдущее
От: Jeff Davis
Дата:
Сообщение: Re: FW: bitemporal functionality for PostgreSQL
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: configurability of OOM killer