Benchmarking Postgres 17 vs. 18
9 comments
·October 14, 2025anarazel
mebcitto
That explains why `sync` and `worker` have so similar results in almost all runs. The benchmarks from Tomas Vondra (https://vondra.me/posts/tuning-aio-in-postgresql-18/) showed some significant differences.
rastignack
Is there now a way to avoid double buffering and use direct IO in postgresql ?
Has anybody seriously benchmarked this ?
I don’t think io uring would make a difference with this setting but I’m curious, as it’s the default for oracle and sybase.
alberth
Am I interrupting the data correctly in that, if you’re running on NVMe - it’s just so fast, that it doesn’t make a difference what mode you pick.
cientifico
That was the same conclusion I got by playing with the graphs.
I concluded that better IO planning it's only worth it for "slow" I/O in 18.
Pretty sure it will bring a lot of learnings. Postgress devs are pretty awesome.
null
6r17
typo *interpreting i guess ?
p_zuckerman
Thanks for posting this interesting article! Do we know if timescale extension is available as well?
travisgriggs
As in timescaledb? Or something else…?
Afaict nothing in this benchmark will actually use AIO in 18. As of 18 there is aio reads for seq scans, bitmap scans, vacuum, and a few other utility commands. But the queries being run should normally be planned as index range scans. We're hoping to the the work for using AIO for index scans into 19, but it could work end up in 20, it's nontrivial.
It's also worth noting that the default for data checksums has changed, with some overhead due to that.