Re: Proposed LogWriter Scheme, WAS: Potential Large - Mailing list pgsql-hackers

From Greg Copeland
Subject Re: Proposed LogWriter Scheme, WAS: Potential Large
Date
Msg-id 1033920399.14342.15.camel@mouse.copelandconsulting.net
Whole thread Raw
In response to Re: Proposed LogWriter Scheme, WAS: Potential Large Performance  ("Curtis Faith" <curtis@galtair.com>)
Responses Re: Proposed LogWriter Scheme, WAS: Potential Large  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Proposed LogWriter Scheme, WAS: Potential Large  (Antti Haapala <antti.haapala@iki.fi>)
List pgsql-hackers
On Sat, 2002-10-05 at 14:46, Curtis Faith wrote:
>
> 2) aio_write vs. normal write.
>
> Since as you and others have pointed out aio_write and write are both
> asynchronous, the issue becomes one of whether or not the copies to the
> file system buffers happen synchronously or not.

Actually, I believe that write will be *mostly* asynchronous while
aio_write will always be asynchronous.  In a buffer poor environment, I
believe write will degrade into a synchronous operation.  In an ideal
situation, I think they will prove to be on par with one another with a
slight bias toward aio_write.  In less than ideal situations where
buffer space is at a premium, I think aio_write will get the leg up.

>
> The kernel doesn't need to know anything about platter rotation. It
> just needs to keep the disk write buffers full enough not to cause
> a rotational latency.


Which is why in a buffer poor environment, aio_write is generally
preferred as the write is still queued even if the buffer is full.  That
means it will be ready to begin placing writes into the buffer, all
without the process having to wait. On the other hand, when using write,
the process must wait.

In a worse case scenario, it seems that aio_write does get a win.

I personally would at least like to see an aio implementation and would
be willing to even help benchmark it to benchmark/validate any returns
in performance.  Surely if testing reflected a performance boost it
would be considered for baseline inclusion?

Greg


pgsql-hackers by date:

Previous
From: Curt Sampson
Date:
Subject: Re: [GENERAL] Performance while loading data and indexing
Next
From: Tom Lane
Date:
Subject: Re: Proposed LogWriter Scheme, WAS: Potential Large