Re: Potential Large Performance Gain in WAL synching

From: Greg Copeland <greg(at)CopelandConsulting(dot)Net>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: Curtis Faith <curtis(at)galtair(dot)com>, 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-05 00:17:56
Message-ID: 1033777076.12986.230.camel@mouse.copelandconsulting.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 2002-10-04 at 18:03, Neil Conway wrote:
> "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.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Giles Lean 2002-10-05 00:49:06 Re: Potential Large Performance Gain in WAL synching
Previous Message Zeugswetter Andreas SB SD 2002-10-04 23:47:12 Re: Potential Large Performance Gain in WAL synching