Re: Automatically sizing the IO worker pool

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Automatically sizing the IO worker pool
Date: 2026-04-08 00:30:46
Message-ID: CA+hUKGJU55K+MA1FSKLWiHkAAKM=uj38Gxe+Fk-br9BafB6Hmw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I changed pgaio_worker_request_grow() not to bother the postmaster
unless nworkers < io_max_workers.

I move that code you wanted outside the loop and did:

/* Choose one worker to wake for this batch. */
if (nsync < num_staged_ios)
worker = pgaio_worker_choose_idle(-1);

I took your suggestion for the names hist_wakeups and hist_ios.

For the location of the following line, I preferred not to separate
the pre-existing tests of StartWorkerNeeded and HaveCrashedWorker,
since they belong together as bgworker concerns.

next_wakeup = maybe_start_io_workers_scheduled_at();

I think I've run out of reasons not to commit this, unless your
pondering of the grow-trigger heuristics revealed a problem?

Attachment Content-Type Size
v6-0001-aio-Adjust-I-O-worker-pool-size-automatically.patch text/x-patch 45.6 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2026-04-08 00:50:11 Re: Implement waiting for wal lsn replay: reloaded
Previous Message Andres Freund 2026-04-08 00:30:44 Re: Automatically sizing the IO worker pool