| From: | "Zeugswetter Andreas ADI SD" <ZeugswetterA(at)spardat(dot)at> |
|---|---|
| To: | <mark(at)mark(dot)mielke(dot)cc>, "NikhilS" <nikkhils(at)gmail(dot)com> |
| Cc: | "Martijn van Oosterhout" <kleptog(at)svana(dot)org>, "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 15:37:48 |
| Message-ID: | E1539E0ED7043848906A8FF995BDA57901726427@m0143.s-mxs.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> > >Good idea, but async i/o is generally poorly supported.
> Only if it can be shown that async I/O actually results in an
> improvement.
sure.
> fix it. So, what is the bottleneck? Is PostgreSQL unable to
> max out the I/O bandwidth? Where? Why?
Yup, that would be the scenario where it helps (provided that you have
a smart disk or a disk array and an intelligent OS aio implementation).
It would be used to fetch the data pages pointed at from an index leaf,
or the next level index pages.
We measured the IO bandwidth difference on Windows with EMC as beeing
nearly proportional to parallel outstanding requests up to at least
16-32.
Andreas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Darcy Buskermolen | 2006-10-20 15:55:36 | Re: misbehaving planer? |
| Previous Message | Tom Lane | 2006-10-20 15:26:06 | Re: misbehaving planer? |