attempts? ▪ Explain the design ▪ Why not any obvious alternative designs? ▪ Why isn’t a part implemented? https://www.postgresql.org/message-id/flat/cf85f46f-b02f-05b2-5248-5000b894ebab%40enterprisedb.com
yet – Haven’t implemented it for this scenario yet ▪ Open questions – Is this part of the design good? ▪ What else needs to be done? – Do I need to implement it for partition tables? ▪ Issues – Why is this test failing? https://www.postgresql.org/message-id/flat/cf85f46f-b02f-05b2-5248-5000b894ebab%40enterprisedb.com https://www.postgresql.org/message-id/flat/CA%2BhUKGJkOiOCa%2Bmag4BF%2BzHo7qo%3Do9CFheB8%3Dg6uT5TUm2gkvA%40mail.gmail.com
important in commit message and email ▪ Try to loop in invested users if user facing or devs if API – CC people who have worked on this problem in the past ▪ Chime in on/review threads in the same subject area
▪ Address review inline point-by-point when sending a new version ▪ Be flexible with stylistic changes ▪ Address all instances of a given type of feedback ▪ Don’t be afraid to fork new mailing list discussions
on average. A trivial example: CREATE TABLE foo(a INT) WITH (autovacuum_enabled=false); INSERT INTO foo SELECT i FROM generate_series(1, 1000) AS i; \timing on VACUUM (VERBOSE) foo; [Paste results here]
▪ Use pgbench – Other supporting benchmarks are okay ▪ Avoid bash scripts and attachments ▪ Minimize distractions ▪ Eliminate extraneous conditions – Use development GUCs, table options when helpful ▪ Minimize runtime
to run https://www.postgresql.org/message-id/flat/CA%2BTgmoa8nddwpMA4Emn7sVoNrQ883mn8ZJBiqXa8dm3puKn%3DqQ%40mail.gmail.com#4251b35792be16116af1c6cf87c2eb5d
explain realistic scenario – e.g. not tpcb-like pgbench with random data access distribution ▪ Describe expected impact and how much of user base it would affect ▪ Outline worst and best cases ▪ Run additional benchmarks with longer runtimes that prove lack of negative interaction with subsystems like checkpointer
than is useful ▪ TPS (Transactions per second) isn’t the only metric – Plan diffs – perf output summary – P99 latency – Memory utilization – Per process IO consumption – …
omnibus commits 3. Each line of a commit is purposeful and clearly outlined in commit message 4. Refactoring should be motivated 5. Functional changes should be obvious 6. Comments and commit messages must clearly communicate risk and action required