Subject: About asynchronous I/O

From: ek ek <[email-masked]>
Date: Tue, 23 Jun 2026 10:55:22 +0300

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?

---

From: bertrand HARTWIG <[email-masked]>
Date: Tue, 23 Jun 2026 13:25:58 +0200

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.

Regards,

Bertrand

> Le 23 juin 2026 à 09:55, ek ek <[email-masked]> 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?

---

From: Ron Johnson <[email-masked]>
Date: Tue, 23 Jun 2026 08:02:54 -0400

On Tue, Jun 23, 2026 at 7:26 AM bertrand HARTWIG <[email-masked]>
wrote:

> 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?

-- 
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!

---

From: bertrand HARTWIG <[email-masked]>
Date: Tue, 23 Jun 2026 14:19:14 +0200

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 <[email-masked]> a écrit :
> 
> On Tue, Jun 23, 2026 at 7:26 AM bertrand HARTWIG <[email-masked] <mailto:[email-masked]>> wrote:
>> Hello,
>> 
>>> Le 23 juin 2026 à 09:55, ek ek <[email-masked] <mailto:[email-masked]>> a écrit :
>>> 
>>> Hello everyone,

---

From: JOHN WIENCEK <[email-masked]>
Date: Tue, 23 Jun 2026 08:04:23 -0500 (CDT)

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 <[email-masked]> wrote:
>  
>  
> > On Tue, Jun 23, 2026 at 7:26 AM bertrand HARTWIG <[email-masked] mailto:[email-masked]> wrote:
> > 
> > > 
> > > Hello,
> > > 
> > > > Le 23 juin 2026 à 09:55, ek ek <[email-masked] mailto:[email-masked]> a écrit :
> > > > 
> > > > Hello everyone,

---

From: bertrand HARTWIG <[email-masked]>
Date: Tue, 23 Jun 2026 15:35:04 +0200

Linux Io_uring is used by PostgreSQL only with aio_read() …

> Le 23 juin 2026 à 15:04, JOHN WIENCEK <[email-masked]> a écrit :
>

---

From: Scott Ribe <[email-masked]>
Date: Tue, 23 Jun 2026 07:58:51 -0600

> Can your application assume the risk of lost transactions in the event of a database crash?

Pretty sure that's not a risk here...

---

From: Ron Johnson <[email-masked]>
Date: Tue, 23 Jun 2026 10:05:42 -0400

> Pretty sure that's not a risk here...

Because WAL writing is sync io?

---

From: Michael Banck <[email-masked]>
Date: Tue, 23 Jun 2026 16:19:57 +0200

> Because WAL writing is sync io?

That, and because AIO is read-only in Postgres so far (including in the
upcoming PG19).

Michael