Re: [SPAM?] Re: Asynchronous I/O Support - Mailing list pgsql-hackers
From | mark@mark.mielke.cc |
---|---|
Subject | Re: [SPAM?] Re: Asynchronous I/O Support |
Date | |
Msg-id | 20061020140501.GA11548@mark.mielke.cc Whole thread Raw |
In response to | Re: Asynchronous I/O Support (NikhilS <nikkhils@gmail.com>) |
Responses |
Re: [SPAM?] Re: Asynchronous I/O Support
("Zeugswetter Andreas ADI SD" <ZeugswetterA@spardat.at>)
Re: [SPAM?] Re: Asynchronous I/O Support (Martijn van Oosterhout <kleptog@svana.org>) |
List | pgsql-hackers |
On Fri, Oct 20, 2006 at 11:13:33AM +0530, NikhilS wrote: > >Good idea, but async i/o is generally poorly supported. > Async i/o is stably supported on most *nix (apart from Linux 2.6.*) plus > Windows. > Guess it would be still worth it, since one fine day 2.6.* will start > supporting it properly too. Only if it can be shown that async I/O actually results in an improvement. Currently, it's speculation, with the one trial implementation showing little to no improvement. Support is a big word in the face of this initial evidence... :-) It's possible that the PostgreSQL design limits the effectiveness of such things. It's possible that PostgreSQL, having been optimized to not use features such as these, has found a way of operating better, contrary to those who believe that async I/O, threads, and so on, are faster. It's possible that async I/O is supported, but poorly implemented on most systems. Take into account that async I/O doesn't guarantee parallel I/O. The concept of async I/O is that an application can proceed to work on other items while waiting for scheduled work in the background. This can be achieved with a background system thread (GLIBC?). There is no requirement that it actually process the requests in parallel. In fact, any system that did process the requests in parallel, would be easier to run to a halt. For example, for the many systems that do not use RAID, we would potentially end up with scattered reads across the disk all running in parallel, with no priority on the reads, which could mean that data we do not yet need is returned first, causing PostgreSQL to be unable to move forwards. If the process is CPU bound at all, this could be an overall loss. Point being, async I/O isn't a magic bullet. There is no evidence that it would improve the situation on any platform. 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? Is PostgreSQL unable to max out the I/O bandwidth? Where? Why? Cheers, mark -- mark@mielke.cc / markm@ncf.ca / markm@nortel.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bindthem... http://mark.mielke.cc/
pgsql-hackers by date: