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 по дате отправления: