Re: Potential Large Performance Gain in WAL synching

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Potential Large Performance Gain in WAL synching
Дата
Msg-id 404.1033787624@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Potential Large Performance Gain in WAL synching  (Neil Conway <neilc@samurai.com>)
Ответы Re: Potential Large Performance Gain in WAL synching
Список pgsql-hackers
Neil Conway <neilc@samurai.com> writes:
> "Curtis Faith" <curtis@galtair.com> writes:
>> It looks to me like BufferAlloc will simply result in a call to
>> BufferReplace > smgrblindwrt > write for md storage manager objects.
>> 
>> This means that a process will block while the write of dirty cache
>> buffers takes place.

> I think Tom was suggesting that when a buffer is written out, the
> write() call only pushes the data down into the filesystem's buffer --
> which is free to then write the actual blocks to disk whenever it
> chooses to.

Exactly --- in all Unix systems that I know of, a write() is
asynchronous unless one takes special pains (like opening the file
with O_SYNC).  Pushing the data from userspace to the kernel disk
buffers does not count as I/O in my mind.

I am quite concerned about Curtis' worries about fsync, though.
There's not any fundamental reason for fsync to block other operations,
but that doesn't mean that it's been implemented reasonably everywhere
:-(.  We need to take a look at that.
        regards, tom lane


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

Предыдущее
От: Joe Conway
Дата:
Сообщение: Re: Improving backend startup interlock
Следующее
От: "Curtis Faith"
Дата:
Сообщение: Re: Potential Large Performance Gain in WAL synching