Re: Automatically sizing the IO worker pool

Jose Luis Tallon <jltallon@adv-solutions.net>

From: Jose Luis Tallon <jltallon@adv-solutions.net>

To: Thomas Munro <thomas.munro@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>

Date: 2025-04-13T17:45:40Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

aio: Adjust I/O worker pool automatically.
- d1c01b79d4ae 19 (unreleased) landed
aio: Simplify pgaio_worker_submit().
- fc44f106657a 19 (unreleased) landed
aio: Remove obsolete IO worker ID references.
- b4c19da93a08 18.0 landed
- 177c1f059338 19 (unreleased) landed
aio: Regularize IO worker internal naming.
- b2afb0676337 18.0 landed
- 01d618bcd782 19 (unreleased) landed

On 12/4/25 18:59, Thomas Munro wrote:
> It's hard to know how to set io_workers=3.

Hmmm.... enable the below behaviour if "io_workers=auto" (default) ?

Sometimes being able to set this kind of parameters manually helps 
tremendously with specific workloads... :S

> [snip]
> Here's a patch to replace that GUC with:
>
>        io_min_workers=1
>        io_max_workers=8
>        io_worker_idle_timeout=60s
>        io_worker_launch_interval=500ms

Great as defaults / backwards compat with io_workers=auto. Sounds more 
user-friendly to me, at least....

> [snip]
>
> Ideas, testing, flames etc welcome.

Logic seems sound, if a bit daunting for inexperienced users --- well, 
maybe just a bit more than it is now, but ISTM evolution should try and 
flatten novices' learning curve, right?

Just .02€, though.

Thanks,

-- 
Parkinson's Law: Work expands to fill the time alloted to it.