Re: About asynchronous I/O

Can your application assume the risk of lost transactions in the event of a database crash?
ASYNC/IO is not a good solution for all applications.

Regards

John

> On 06/23/2026 7:19 AM CDT bertrand HARTWIG <hartwig(dot)bertrand(at)gmail(dot)com> wrote:
>
>
> Very usefull on SSD AND nvme ! (low latency on IOPs). But the higher the disk latency, the greater the gains you will notice.
>
> On SSD i observed 200%
>
>
> > Le 23 juin 2026 à 14:02, Ron Johnson <ronljohnsonjr(at)gmail(dot)com> a écrit :
> > On Tue, Jun 23, 2026 at 7:26 AM bertrand HARTWIG <hartwig(dot)bertrand(at)gmail(dot)com mailto:hartwig(dot)bertrand(at)gmail(dot)com> wrote:
> >
> > >
> > > Hello,
> > >
> > > The size of the database is clearly not important.
> > >
> > > What matters are queries that are not already cached and that perform I/O.
> > >
> > > With async I/O, you can see I/O performance improvements of up to 200%–300%. The higher the disk latency, the greater the gains you will notice.
> > >
> >
> > So, not so useful on SSD/NVMe?
> >
> >
> > >
> > > Regards,
> > >
> > > Bertrand
> > >
> > >
> > > > Le 23 juin 2026 à 09:55, ek ek <livadidrive(at)gmail(dot)com mailto:livadidrive(at)gmail(dot)com> a écrit :
> > > >
> > > > Hello everyone,
> > > > Are any of you running PostgreSQL 18 on production environments sized between 1 to 3TB? Does the 'asynchronous I/O (AIO) subsystem' deliver a significant performance increase? Also, has anyone had the opportunity to benchmark it against v17?
> > > >
> > >
> >
> >
> > --
> > Death to <Redacted>, and butter sauce.
> > Don't boil me, I'm still alive.
> > <Redacted> lobster!
> >
>