On Fri, Oct 20, 2006 at 10:05:01AM -0400, [EMAIL PROTECTED] wrote: > 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... :-)
Yeah, the single test so far on a system that didn't support asyncronous I/O doesn't prove anything. It would help if there was a reasonable system that did support async i/o so it could be tested properly. > Point being, async I/O isn't a magic bullet. There is no evidence that it > would improve the situation on any platform. I think it's likely to help with index scan. Prefetching index leaf pages I think could be good. As would prefectching pages from a (bitmap) index scan. It won't help much on very simple queries, but where it should shine is a merge join across two index scans. Currently postgresql would do something like: Loop Fetch left tuple for join Fetch btree leaf Fetch tuple off disk Fetch right tuples for join Fetch btree leaf Fetch tuple off disk Currently it fetches a block fro one file, then a block from the other, back and forth. with async i/o you could read from both files and the indexes simultaneously, thus is theory leading to better i/o throughput. > 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? For systems where postgresql is unable to saturate the i/o bandwidth, this is the proposed solution. Are there others? Have a nice day, -- Martijn van Oosterhout <email@example.com> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate.
Description: Digital signature