From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Álvaro Herrera <alvherre(at)kurilemu(dot)de> |
Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Should io_method=worker remain the default? |
Date: | 2025-09-03 16:05:13 |
Message-ID: | g2yfmfoft7vxkqpv7zislnlt5fzuria2qvpnm66uscc2rd666r@5pcv7tcm4mzz |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2025-09-03 17:53:55 +0200, Álvaro Herrera wrote:
> On 2025-Sep-02, Jeff Davis wrote:
>
> > The good news is that io_uring seemed to solve the problem.
> > Unfortunately, that's platform-specific, so it can't be the default.
>
> Why not? We have had wal_sync_method with a platform-dependent default
> for a very long time.
At least for now there are other reasons:
1) io_uring needs a higher ulimit -n, because we need to create an io_uring
instance for each proc entry, in postmaster. In the future, we might want
to increase soft ulimit -n, but we aren't doing that yet.
In older kernels the number of io_uring memory mapping also can pose a
performance issue at high connection rates.
2) Sometimes worker is faster than io_uring, specifically when checksums are
enabled. Workers can offload the checksum computations, io_uring can't.
3) We can't, at build time, know whether io_uring is actually available at
runtime. io_uring can be disabled with a runtime sysctl.
We could add a dynamic fallback to worker, but we don't have that yet.
Anyway, the issue with worker in this case isn't inherent, it's just a bit of
lock contention in an extreme workload...
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2025-09-03 16:15:46 | Re: Solaris compiler status |
Previous Message | Jacob Champion | 2025-09-03 15:58:28 | Re: Explicitly enable meson features in CI |