Re: About asynchronous I/O

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

> Le 23 juin 2026 à 15:04, JOHN WIENCEK <jwiencek3(at)comcast(dot)net> 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 <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!