Exercising PostgreSQL Performance Enhancing Patches
October 20–23
Writing a PostgreSQL performance patch requires more than identifying an optimization and implementing it. To propose the change effectively, you need a clear performance reproducer, meaningful measurements, and an understanding of the conditions where the patch helps, has little effect, or introduces tradeoffs.
This talk will cover a few practical techniques for designing benchmarks for PostgreSQL performance patches. We will look at how to turn an observed inefficiency, either from reading the code or from a real workload, into a minimal reproducer suitable for discussion on pgsql-hackers. We will discuss how to identify best-case and worst-case scenarios and how to scale a benchmark down without accidentally moving the bottleneck somewhere else.
The talk will also cover cases where the system must be in a particular state before the performance effect appears: for example, when checkpoint timing, page visibility state, or concurrent activity matter. We will discuss practical techniques such as tuning checkpoint behavior, using or disabling WAL compression, configuring OS settings, and shaping the workload so that the benchmark exercises the intended part of PostgreSQL.
The goal is to construct performance test cases that are small enough to share, realistic enough to be meaningful, and precise enough to help reviewers evaluate a proposed PostgreSQL patch.
