Re: [SPAM?] Re: Asynchronous I/O Support

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: mark(at)mark(dot)mielke(dot)cc, NikhilS <nikkhils(at)gmail(dot)com>, Mark Kirkwood <markir(at)paradise(dot)net(dot)nz>, Luke Lonergan <llonergan(at)greenplum(dot)com>, Raja Agrawal <raja(dot)agrawal(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [SPAM?] Re: Asynchronous I/O Support
Date: 2006-10-20 18:21:04
Message-ID: 17101.1161368464@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Fri, Oct 20, 2006 at 10:05:01AM -0400, mark(at)mark(dot)mielke(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Merlin Moncure 2006-10-20 19:04:55 Re: [SPAM?] Re: Asynchronous I/O Support
Previous Message Magnus Hagander 2006-10-20 18:15:28 Re: zic with msvc