Re: [SPAM?] Re: Asynchronous I/O Support - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [SPAM?] Re: Asynchronous I/O Support
Date
Msg-id 17101.1161368464@sss.pgh.pa.us
Whole thread Raw
In response to Re: [SPAM?] Re: Asynchronous I/O Support  (Martijn van Oosterhout <kleptog@svana.org>)
Responses Re: [SPAM?] Re: Asynchronous I/O Support  ("Merlin Moncure" <mmoncure@gmail.com>)
List pgsql-hackers
> On Fri, Oct 20, 2006 at 10:05:01AM -0400, mark@mark.mielke.cc wrote:
>> One would need to consider the PostgreSQL architecture, determine where
>> the bottleneck actually is, and understand why it is a bottleneck fully,
>> before one could decide how to fix it. So, what is the bottleneck?

I think Mark's point is not being taken sufficiently to heart in this
thread.

It's not difficult at all to think of reasons why attempted read-ahead
could be a net loss.  One that's bothering me right at the moment is
that each such request would require a visit to the shared buffer
manager to see if we already have the desired page in buffers.  (Unless
you think it'd be cheaper to force the kernel to uselessly read the
page...)  Then another visit when we actually need the page.  That means
that readahead will double the contention for the buffer manager locks,
which is likely to put us right back into the context swap storm problem
that we've spent the last couple of releases working out of.

So far I've seen no evidence that async I/O would help us, only a lot
of wishful thinking.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Magnus Hagander"
Date:
Subject: Re: [PATCHES] zic with msvc
Next
From: "Merlin Moncure"
Date:
Subject: Re: [SPAM?] Re: Asynchronous I/O Support