Re: Reworking WAL locking

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Reworking WAL locking
Дата
Msg-id 19399.1203025842@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Reworking WAL locking  (Simon Riggs <simon@2ndquadrant.com>)
Ответы Re: Reworking WAL locking
Список pgsql-hackers
Simon Riggs <simon@2ndquadrant.com> writes:
> On Thu, 2008-02-14 at 13:52 -0500, Tom Lane wrote:
>> [ still staring at the code ... ]  Something that might be interesting
>> though is to try to move some of the buffer control logic overhead out
>> of WALInsertLock's domain and into WALWriteLock's domain.

> I like this one because its another example that contention is not
> static, seems like its more often cyclical. The WALInsertLock is held
> longer than normal when we cross page boundaries, creating a pulsing
> effect thru the lock queue.

Yeah, significantly longer than normal if you assume the normal case is
to write a WAL record that's much less than a full page.  But has anyone
seen direct evidence that that's an important effect?  I was just
proposing this on speculation --- if there's already evidence that that
behavior is a problem, it'd be interesting to see it.

BTW, we'd probably need to do something like this even if we then go
forward with your original idea.  If we're going to allow multiple
backends to be inserting WAL records into the-same-or-different WAL
buffers concurrently, we can't have that same code responsible for
initializing empty buffers.
        regards, tom lane


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

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Reworking WAL locking
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Show INHERIT in \du