• Postgres History: The Postgres open source project is nearly 30 years old. The author started using it about 20 years ago and has been contributing code for at least 10 years. It's hard to judge performance changes over the years, so the author did benchmarks.
• Benchmark Challenges: Answering performance questions is hard as there's no good data for comparing many Postgres releases. Development benchmarks are often focused on specific features and code areas, not major releases. Application metrics are also limited as systems don't go through every major release and workloads change over time.
• Hardware Considerations: The author picked a hardware configuration from ~2016 for benchmarks as comparable systems weren't available in 2004. This helps make the comparison understandable and focused on Postgres.
• Postgres Releases: The author built and tested 20 Postgres releases starting from 8.0. It was a challenging process due to the evolution of external tools like bison and flex. Some builds had issues, and the author had to make adjustments.
• pgbench Tool: pgbench is a traditional tool for benchmarking Postgres. The author used two built-in workloads (read-only and read-write) with various parameters to test different cases. There were 1680 combinations to test, and each combination was run 3 times for 5 minutes.
• Postgresql.conf: To get a fair comparison of performance over time, the author used a similar configuration for all releases. This included settings like shared_buffers, checkpoint_timeout, etc.
• Results Overview: The results show that read-only pgbench on a small data set is fastest with simple queries after warming up. There were big improvements in 9.2 and 9.6, and later releases handled higher client counts better. Similar behaviors were observed for read-write workloads and different data set sizes.
• Main Improvements: Most performance improvements happened in a few releases like 9.2, 9.5, 9.6, 14, and 18dev. The release notes mention scalability and multi-core system improvements.
• Conclusions: The period of explosive speedups seems to be over, and future improvements will likely be incremental. However, this doesn't apply to all OLTP workloads, and patches for specific cases can still lead to significant improvements. Feedback can be provided via email.