Benchmarking Postgres 17 vs. 18
planetscale.com
Benchmarking Postgres 17 vs. 18
1–10 of 68 posts
Re: Benchmarking Postgres 17 vs. 18
#2Am 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.
Re: Benchmarking Postgres 17 vs. 18
#3Am 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.
[deleted]
Re: Benchmarking Postgres 17 vs. 18
#4Afaict 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.
Re: Benchmarking Postgres 17 vs. 18
#5Afaict 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 chan…
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.
Re: Benchmarking Postgres 17 vs. 18
#6Am 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.
typo *interpreting i guess ?
Re: Benchmarking Postgres 17 vs. 18
#7Thanks for posting this interesting article! Do we know if timescale extension is available as well?
Re: Benchmarking Postgres 17 vs. 18
#8Thanks for posting this interesting article! Do we know if timescale extension is available as well?
As in timescaledb? Or something else…?
Re: Benchmarking Postgres 17 vs. 18
#9Am 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.
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.
Re: Benchmarking Postgres 17 vs. 18
#10Is 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.