Horton
Menu

Re: Automatically sizing the IO worker pool

Thomas Munro <thomas.munro@gmail.com>

View thread
From: Thomas Munro <thomas.munro@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Dmitry Dolgov <9erthalion6@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-04-08T00:30:46Z
Lists: pgsql-hackers

Attachments

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?

Commits

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

  1. aio: Adjust I/O worker pool automatically.

  2. Convert lwlock.c to use the new shmem allocation functions

  3. aio: Simplify pgaio_worker_submit().

  4. Conditional locking in pgaio_worker_submit_internal

  5. aio: Remove obsolete IO worker ID references.

  6. aio: Regularize IO worker internal naming.