|From:||Julian Markwort <julian(dot)markwort(at)uni-muenster(dot)de>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Cc:||Andres Freund <andres(at)anarazel(dot)de>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, David Steele <david(at)pgmasters(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, marius(dot)timmer(at)uni-muenster(dot)de, arne(dot)scheffer(at)uni-muenster(dot)de|
|Subject:||Re: [HACKERS] [FEATURE PATCH] pg_stat_statements with plans (v02)|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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
> 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
The patched version is now 99.95% as fast as unmodified
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
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
b) Would you like to be able to tune the percentiles yourself, to
adjust for the point at which a new plan is stored?
|Next Message||Julian Markwort||2018-03-08 13:58:34||Re: [HACKERS] [FEATURE PATCH] pg_stat_statements with plans (v02)|
|Previous Message||Alvaro Herrera||2018-03-08 13:46:56||Re: Failed to request an autovacuum work-item in silence|