Tom Lane wrote on 2018-03-02: > You need to make your changes in a 1.5--1.6 > upgrade file. Otherwise there's no clean path for existing > installations > to upgrade to the new version.
I've adressed all the issues that were brought up so far: 1. there is now only an added 1.5--1.6.sql file. 2. the overhead, as previously discussed (as much as a 12% decrease in TPS during read-only tests), is now gone, the problem was that I was collecting the plan String before checking if it needed to be stored at all. The patched version is now 99.95% as fast as unmodified pg_stat_statements. 3. I've cleaned up my own code and made sure it adheres to GNU C coding style, I was guilty of some // comments and curly brackets were sometimes in the same line as my control structures. I'd love to hear more feedback, here are two ideas to polish this patch: a) Right now, good_plan and bad_plan collection can be activated and deactivated with separate GUCs. I think it would be sensible to collect either both or none. (This would result in fewer convoluted conditionals.) b) Would you like to be able to tune the percentiles yourself, to adjust for the point at which a new plan is stored? Greetings Julian
smime.p7s
Description: S/MIME cryptographic signature