Re: Potential Large Performance Gain in WAL synching
От | Greg Copeland |
---|---|
Тема | Re: Potential Large Performance Gain in WAL synching |
Дата | |
Msg-id | 1033777076.12986.230.camel@mouse.copelandconsulting.net обсуждение исходный текст |
Ответ на | Re: Potential Large Performance Gain in WAL synching (Neil Conway <neilc@samurai.com>) |
Список | pgsql-hackers |
On Fri, 2002-10-04 at 18:03, Neil Conway wrote: > "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. In other words, the write() returns, the backend process > can continue with what it was doing, and at some later time the blocks > that we flushed from the Postgres buffer will actually be written to > disk. So in some sense of the word, that I/O is asynchronous. Isn't that true only as long as there is buffer space available? When there isn't buffer space available, seems the window for blocking comes into play?? So I guess you could say it is optimally asynchronous and worse case synchronous. I think the worse case situation is one which he's trying to address. At least that's how I interpret it. Greg
В списке pgsql-hackers по дате отправления: