Re: xlog.c: WALInsertLock vs. WALWriteLock

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: xlog.c: WALInsertLock vs. WALWriteLock
Дата
Msg-id 4CC71A65.4090703@enterprisedb.com
обсуждение исходный текст
Ответ на Re: xlog.c: WALInsertLock vs. WALWriteLock  (fazool mein <fazoolmein@gmail.com>)
Ответы Re: xlog.c: WALInsertLock vs. WALWriteLock  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On 26.10.2010 21:03, fazool mein wrote:
>> Might I suggest adopting the same technique walsender does, ie just read
>> the data back from disk?  There's a reason why we gave up trying to have
>> walsender read directly from the buffers.
>>
> That is exactly what I do not want to do, i.e. read from disk, as long as
> the piece of WAL is available in the buffers.

Why not? If the reason is performance, I'd like to see some performance 
numbers to show that it's worth the trouble. You could perhaps do a 
quick and dirty hack that doesn't do the locking 100% correctly first, 
and do some benchmarking on that to get a ballpark number of how much 
potential there is. Or run oprofile on the current walsender 
implementation to see how much time is currently spent reading WAL from 
the kernel buffers.

> Can you please describe why
> walsender reading directly from the buffers was given up? To avoid a lot of
> locking?

To avoid locking yes, and complexity in general.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


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

Предыдущее
От: fazool mein
Дата:
Сообщение: Re: xlog.c: WALInsertLock vs. WALWriteLock
Следующее
От: Peter Eisentraut
Дата:
Сообщение: security label error message