public inbox for [email protected]
help / color / mirror / Atom feedAbout asynchronous I/O
9+ messages / 6 participants
[nested] [flat]
* About asynchronous I/O
@ 2026-06-23 07:55 ek ek <[email protected]>
2026-06-23 11:25 ` Re: About asynchronous I/O bertrand HARTWIG <[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 07:55 About asynchronous I/O ek ek <[email protected]>
@ 2026-06-23 11:25 ` bertrand HARTWIG <[email protected]>
2026-06-23 12:02 ` Re: About asynchronous I/O Ron Johnson <[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 07:55 About asynchronous I/O ek ek <[email protected]>
2026-06-23 11:25 ` Re: About asynchronous I/O bertrand HARTWIG <[email protected]>
@ 2026-06-23 12:02 ` Ron Johnson <[email protected]>
2026-06-23 12:19 ` Re: About asynchronous I/O 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 07:55 About asynchronous I/O ek ek <[email protected]>
2026-06-23 11:25 ` Re: About asynchronous I/O bertrand HARTWIG <[email protected]>
2026-06-23 12:02 ` Re: About asynchronous I/O Ron Johnson <[email protected]>
@ 2026-06-23 12:19 ` bertrand HARTWIG <[email protected]>
2026-06-23 13:04 ` Re: About asynchronous I/O JOHN WIENCEK <[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 07:55 About asynchronous I/O ek ek <[email protected]>
2026-06-23 11:25 ` Re: About asynchronous I/O bertrand HARTWIG <[email protected]>
2026-06-23 12:02 ` Re: About asynchronous I/O Ron Johnson <[email protected]>
2026-06-23 12:19 ` Re: About asynchronous I/O bertrand HARTWIG <[email protected]>
@ 2026-06-23 13:04 ` JOHN WIENCEK <[email protected]>
2026-06-23 13:35 ` Re: About asynchronous I/O bertrand HARTWIG <[email protected]>
2026-06-23 13:58 ` Re: About asynchronous I/O Scott Ribe <[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 07:55 About asynchronous I/O ek ek <[email protected]>
2026-06-23 11:25 ` Re: About asynchronous I/O bertrand HARTWIG <[email protected]>
2026-06-23 12:02 ` Re: About asynchronous I/O Ron Johnson <[email protected]>
2026-06-23 12:19 ` Re: About asynchronous I/O bertrand HARTWIG <[email protected]>
2026-06-23 13:04 ` Re: About asynchronous I/O JOHN WIENCEK <[email protected]>
@ 2026-06-23 13:35 ` bertrand HARTWIG <[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 07:55 About asynchronous I/O ek ek <[email protected]>
2026-06-23 11:25 ` Re: About asynchronous I/O bertrand HARTWIG <[email protected]>
2026-06-23 12:02 ` Re: About asynchronous I/O Ron Johnson <[email protected]>
2026-06-23 12:19 ` Re: About asynchronous I/O bertrand HARTWIG <[email protected]>
2026-06-23 13:04 ` Re: About asynchronous I/O JOHN WIENCEK <[email protected]>
@ 2026-06-23 13:58 ` Scott Ribe <[email protected]>
2026-06-23 14:05 ` Re: About asynchronous I/O Ron Johnson <[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 07:55 About asynchronous I/O ek ek <[email protected]>
2026-06-23 11:25 ` Re: About asynchronous I/O bertrand HARTWIG <[email protected]>
2026-06-23 12:02 ` Re: About asynchronous I/O Ron Johnson <[email protected]>
2026-06-23 12:19 ` Re: About asynchronous I/O bertrand HARTWIG <[email protected]>
2026-06-23 13:04 ` Re: About asynchronous I/O JOHN WIENCEK <[email protected]>
2026-06-23 13:58 ` Re: About asynchronous I/O Scott Ribe <[email protected]>
@ 2026-06-23 14:05 ` Ron Johnson <[email protected]>
2026-06-23 14:19 ` Re: About asynchronous I/O Michael Banck <[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 07:55 About asynchronous I/O ek ek <[email protected]>
2026-06-23 11:25 ` Re: About asynchronous I/O bertrand HARTWIG <[email protected]>
2026-06-23 12:02 ` Re: About asynchronous I/O Ron Johnson <[email protected]>
2026-06-23 12:19 ` Re: About asynchronous I/O bertrand HARTWIG <[email protected]>
2026-06-23 13:04 ` Re: About asynchronous I/O JOHN WIENCEK <[email protected]>
2026-06-23 13:58 ` Re: About asynchronous I/O Scott Ribe <[email protected]>
2026-06-23 14:05 ` Re: About asynchronous I/O Ron Johnson <[email protected]>
@ 2026-06-23 14:19 ` Michael Banck <[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