Re: Potential Large Performance Gain in WAL synching

From: Neil Conway <neilc(at)samurai(dot)com>
To: "Curtis Faith" <curtis(at)galtair(dot)com>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Pgsql-Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Potential Large Performance Gain in WAL synching
Date: 2002-10-04 23:03:59
Message-ID: 873crlajs0.fsf@mailbox.samurai.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Curtis Faith" <curtis(at)galtair(dot)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.

Cheers,

Neil

--
Neil Conway <neilc(at)samurai(dot)com> || PGP Key ID: DB3C29FC

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Giles Lean 2002-10-04 23:24:55 Re: Improving backend startup interlock
Previous Message Alvaro Herrera 2002-10-04 22:21:06 Re: ALTER TABLE ... ADD COLUMN