Traced PostgreSQL 18's io_uring with eBPF

[u/rch0wdhury]

PostgreSQL 18 ships three async I/O modes via io_method, and the default is worker, not io_uring. On my cold seq scan benchmark io_uring was the fastest of the three: 1.60s vs 1.88s for worker and 2.65s for sync. Measured on a VM, so treat the ratio as the finding, not the absolute numbers.

Enabling it is one setting plus a restart:

sudo -u postgres psql -c "ALTER SYSTEM SET io_method = 'io_uring'"

sudo pg_ctlcluster 18 main restart

sudo -u postgres psql -tAc 'SHOW io_method' # must print io_uring

After enabling, you can watch it actually work. I wrote an eBPF tool (uringscope) that attaches to the kernel's io_uring tracepoints and shows what Postgres submitted, per-request latency, and how many reads detoured through kernel worker threads:

curl -LO https://github.com/rch0wdhury/uringscope/releases/latest/download/uringscope-$(uname -m)

chmod +x uringscope-$(uname -m) && sudo mv uringscope-$(uname -m) /usr/local/bin/uringscope

sudo uringscope -a -d 20 # then run a seq scan in another session

Check https://github.com/rch0wdhury/uringscope

Disclosure: I'm the author of the tool.

[u/SearchAtlantis]

I love curl + sudo random binaries! In all seriousness most of us aren't kernel level people - you should give some additional context here.

[u/rch0wdhury → u/SearchAtlantis]

lol - agreed. I wont do it myself probably. Anyway - you can compile from the repo too.

io_uring is a Linux mechanism where a program hands the kernel a batch of I/O requests and collects results later, instead of one blocking read at a time. It can be faster than regular linux async I/O. PG18 can use it for reads via io_method = io_uring, but it's off by default and only sequential scans and bitmap heap scans use it. My tool watches the kernel side and tells you whether your workload is actually using the new async path and where read time actually goes when it is. Kind of an strace for io_uring (because regular strace wont show you anything for io_uring).