public inbox for [email protected]help / color / mirror / Atom feed
About asynchronous I/O 9+ messages / 6 participants [nested] [flat]
* About asynchronous I/O @ 2026-06-23 07:55 ek ek <[email protected]> 0 siblings, 1 reply; 9+ messages in thread From: ek ek @ 2026-06-23 07:55 UTC (permalink / raw) To: Pgsql-admin <[email protected]> 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? ^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: About asynchronous I/O @ 2026-06-23 11:25 bertrand HARTWIG <[email protected]> parent: ek ek <[email protected]> 0 siblings, 1 reply; 9+ messages in thread From: bertrand HARTWIG @ 2026-06-23 11:25 UTC (permalink / raw) To: ek ek <[email protected]>; +Cc: Pgsql-admin <[email protected]> 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 protected]> 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? ^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: About asynchronous I/O @ 2026-06-23 12:02 Ron Johnson <[email protected]> parent: bertrand HARTWIG <[email protected]> 0 siblings, 1 reply; 9+ messages in thread From: Ron Johnson @ 2026-06-23 12:02 UTC (permalink / raw) To: Pgsql-admin <[email protected]> On Tue, Jun 23, 2026 at 7:26 AM bertrand HARTWIG <[email protected]> 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 <[email protected]> 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! ^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: About asynchronous I/O @ 2026-06-23 12:19 bertrand HARTWIG <[email protected]> parent: Ron Johnson <[email protected]> 0 siblings, 1 reply; 9+ messages in thread From: bertrand HARTWIG @ 2026-06-23 12:19 UTC (permalink / raw) To: Ron Johnson <[email protected]>; +Cc: Pgsql-admin <[email protected]> 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 protected]> a écrit : > > On Tue, Jun 23, 2026 at 7:26 AM bertrand HARTWIG <[email protected] <mailto:[email protected]>> 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 <[email protected] <mailto:[email protected]>> 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! ^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: About asynchronous I/O @ 2026-06-23 13:04 JOHN WIENCEK <[email protected]> parent: bertrand HARTWIG <[email protected]> 0 siblings, 2 replies; 9+ messages in thread From: JOHN WIENCEK @ 2026-06-23 13:04 UTC (permalink / raw) To: bertrand HARTWIG <[email protected]>; Ron Johnson <[email protected]>; +Cc: Pgsql-admin <[email protected]> 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 protected]> 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 <[email protected]> a écrit : > > On Tue, Jun 23, 2026 at 7:26 AM bertrand HARTWIG <[email protected] mailto:[email protected]> 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 <[email protected] mailto:[email protected]> 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! > > > ^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: About asynchronous I/O @ 2026-06-23 13:35 bertrand HARTWIG <[email protected]> parent: JOHN WIENCEK <[email protected]> 1 sibling, 0 replies; 9+ messages in thread From: bertrand HARTWIG @ 2026-06-23 13:35 UTC (permalink / raw) To: JOHN WIENCEK <[email protected]>; +Cc: Ron Johnson <[email protected]>; Pgsql-admin <[email protected]> Linux Io_uring is used by PostgreSQL only with aio_read() … > Le 23 juin 2026 à 15:04, JOHN WIENCEK <[email protected]> a écrit : > > 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 protected]> 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 <[email protected]> a écrit : >>> On Tue, Jun 23, 2026 at 7:26 AM bertrand HARTWIG <[email protected] <mailto:[email protected]>> 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 <[email protected] <mailto:[email protected]>> 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! ^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: About asynchronous I/O @ 2026-06-23 13:58 Scott Ribe <[email protected]> parent: JOHN WIENCEK <[email protected]> 1 sibling, 1 reply; 9+ messages in thread From: Scott Ribe @ 2026-06-23 13:58 UTC (permalink / raw) To: JOHN WIENCEK <[email protected]>; +Cc: bertrand HARTWIG <[email protected]>; Ron Johnson <[email protected]>; Pgsql-admin <[email protected]> On Jun 23, 2026, at 7:04 AM, JOHN WIENCEK <[email protected]> wrote: > > Can your application assume the risk of lost transactions in the event of a database crash? Pretty sure that's not a risk here... ^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: About asynchronous I/O @ 2026-06-23 14:05 Ron Johnson <[email protected]> parent: Scott Ribe <[email protected]> 0 siblings, 1 reply; 9+ messages in thread From: Ron Johnson @ 2026-06-23 14:05 UTC (permalink / raw) To: Pgsql-admin <[email protected]> On Tue, Jun 23, 2026 at 9:59 AM Scott Ribe <[email protected]> wrote: > On Jun 23, 2026, at 7:04 AM, JOHN WIENCEK <[email protected]> wrote: > > > > Can your application assume the risk of lost transactions in the event > of a database crash? > > Pretty sure that's not a risk here... > Because WAL writing is sync io? -- Death to <Redacted>, and butter sauce. Don't boil me, I'm still alive. <Redacted> lobster! ^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: About asynchronous I/O @ 2026-06-23 14:19 Michael Banck <[email protected]> parent: Ron Johnson <[email protected]> 0 siblings, 0 replies; 9+ messages in thread From: Michael Banck @ 2026-06-23 14:19 UTC (permalink / raw) To: Ron Johnson <[email protected]>; +Cc: Pgsql-admin <[email protected]> On Tue, Jun 23, 2026 at 10:05:42AM -0400, Ron Johnson wrote: > On Tue, Jun 23, 2026 at 9:59 AM Scott Ribe <[email protected]> > wrote: > > On Jun 23, 2026, at 7:04 AM, JOHN WIENCEK <[email protected]> wrote: > > > Can your application assume the risk of lost transactions in the event > > of a database crash? > > > > Pretty sure that's not a risk here... > > Because WAL writing is sync io? That, and because AIO is read-only in Postgres so far (including in the upcoming PG19). Michael ^ permalink raw reply [nested|flat] 9+ messages in thread
end of thread, other threads:[~2026-06-23 14:19 UTC | newest] Thread overview: 9+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-06-23 07:55 About asynchronous I/O ek ek <[email protected]> 2026-06-23 11:25 ` bertrand HARTWIG <[email protected]> 2026-06-23 12:02 ` Ron Johnson <[email protected]> 2026-06-23 12:19 ` bertrand HARTWIG <[email protected]> 2026-06-23 13:04 ` JOHN WIENCEK <[email protected]> 2026-06-23 13:35 ` bertrand HARTWIG <[email protected]> 2026-06-23 13:58 ` Scott Ribe <[email protected]> 2026-06-23 14:05 ` Ron Johnson <[email protected]> 2026-06-23 14:19 ` Michael Banck <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox