Re: [HACKERS] [FEATURE PATCH] pg_stat_statements with plans (v02)

2018-03-20 Thread Julian Markwort
I just realized I made a whitespace error when I modified the comments. I hope I don't make a habit of sending erroneous mails. Please accept my apologies, as well as a guaranteed whitespace-error-free patch (updated to version 5 for clarity). Julian Julian Markwort schrieb am 2018-03-20: > To

Re: [HACKERS] [FEATURE PATCH] pg_stat_statements with plans (v02)

2018-03-20 Thread Julian Markwort
To anyone who followed along with this for so long, I'd like to present my newest version of this patch. As suggested by Arthur Zakirov, there is now only a single GUC ( pg_stat_statements.plan_track ) responsible for the selection of the plans that should be tracked. Possible values are: all,

Re: [HACKERS] [FEATURE PATCH] pg_stat_statements with plans (v02)

2018-03-13 Thread Arthur Zakirov
On Mon, Mar 12, 2018 at 02:11:42PM +0100, Julian Markwort wrote: > > In same manner pg_stat_statements_good_plan_reset() and > > pg_stat_statements_bad_plan_reset() functions can be combined in > > function: > > > pg_stat_statements_plan_reset(in queryid bigint, in good boolean, in bad > >

Re: [HACKERS] [FEATURE PATCH] pg_stat_statements with plans (v02)

2018-03-12 Thread Julian Markwort
Arthur Zakirov wrote on 2018-03-09: > I'd like to review the patch and leave a feedback. I tested it with > different indexes on same table and with same queries and it works fine. Thanks for taking some time to review my patch, Arthur! > First of all, GUC variables and functions. How about

Re: [HACKERS] [FEATURE PATCH] pg_stat_statements with plans (v02)

2018-03-09 Thread Arthur Zakirov
Greetings, On Thu, Mar 08, 2018 at 02:58:34PM +0100, Julian Markwort wrote: > > 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

Re: [HACKERS] [FEATURE PATCH] pg_stat_statements with plans (v02)

2018-03-08 Thread Julian Markwort
I've goofed up now, sorry for failing to attach my updated patch. Am Donnerstag, den 08.03.2018, 14:55 +0100 schrieb Julian Markwort: > 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 >

Re: [HACKERS] [FEATURE PATCH] pg_stat_statements with plans (v02)

2018-03-08 Thread Julian Markwort
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.

Re: [HACKERS] [FEATURE PATCH] pg_stat_statements with plans (v02)

2018-03-02 Thread Tom Lane
Julian Markwort writes: > Andres Freund wrote on 2018-03-02: >> and I'd checked that 1.5 already exists. But you just renamed the file, >> presumably because it's essentially rewriting the whole file? I'm not >> sure I'm a big fan of doing so, because that makes

Re: [HACKERS] [FEATURE PATCH] pg_stat_statements with plans (v02)

2018-03-02 Thread Julian Markwort
Andres Freund wrote on 2018-03-02: > Yea, I misread the diff to think you added a conflicting version. Due > to: > -DATA =3D pg_stat_statements--1.4.sql pg_stat_statements--1.4--1.5.sql \ > +DATA =3D pg_stat_statements--1.5.sql pg_stat_statements--1.4--1.5.sql \ > and I'd checked that 1.5 already

Re: [HACKERS] [FEATURE PATCH] pg_stat_statements with plans (v02)

2018-03-02 Thread Tom Lane
Andres Freund writes: > Yea, I misread the diff to think you added a conflicting version. Due > to: > -DATA =3D pg_stat_statements--1.4.sql pg_stat_statements--1.4--1.5.sql \ > +DATA =3D pg_stat_statements--1.5.sql pg_stat_statements--1.4--1.5.sql \ > and I'd checked that 1.5

Re: [HACKERS] [FEATURE PATCH] pg_stat_statements with plans (v02)

2018-03-02 Thread Andres Freund
On 2018-03-02 18:07:32 +0100, Julian Markwort wrote: > Andres Freund wrote on 2018-03-01: > > I think the patch probably doesn't apply anymore, due to other changes > > to pg_stat_statements since its posting. Could you refresh? > > pgss_plans_v02.patch applies cleanly to master, there were no

Re: [HACKERS] [FEATURE PATCH] pg_stat_statements with plans (v02)

2018-03-02 Thread Julian Markwort
Andres Freund wrote on 2018-03-01: > I think the patch probably doesn't apply anymore, due to other changes > to pg_stat_statements since its posting. Could you refresh? pgss_plans_v02.patch applies cleanly to master, there were no changes to pg_stat_statements since the copyright updates at the

Re: [HACKERS] [FEATURE PATCH] pg_stat_statements with plans (v02)

2018-03-01 Thread Andres Freund
Hi, On 2018-01-10 15:05:39 +0100, Julian Markwort wrote: > I'd like to follow up to my previous proposition of tracking (some) best and > worst plans for different queries in the pg_stat_statements extension. Cool feature. I think the patch probably doesn't apply anymore, due to other changes

Re: [HACKERS] [FEATURE PATCH] pg_stat_statements with plans (v02)

2018-01-15 Thread Julian Markwort
On 01/11/2018 03:43 PM, David Fetter wrote: Is the assumption of a normal distribution reasonable for outlier plans as you've seen them? This is a difficult but fair question. First of all, I'd like to clarify that the normal distribution is assumed for the set of all execution times matching

Re: [HACKERS] [FEATURE PATCH] pg_stat_statements with plans (v02)

2018-01-11 Thread David Fetter
On Wed, Jan 10, 2018 at 03:05:39PM +0100, Julian Markwort wrote: > Hello hackers, > > I'd like to follow up to my previous proposition of tracking (some) best and > worst plans for different queries in the pg_stat_statements extension. > > Based on the comments and suggestions made towards my

Re: [HACKERS] [FEATURE PATCH] pg_stat_statements with plans (v02)

2018-01-10 Thread Julian Markwort
Hello hackers, I'd like to follow up to my previous proposition of tracking (some) best and worst plans for different queries in the pg_stat_statements extension. Based on the comments and suggestions made towards my last endeavour, I've taken the path of computing the interquartile distance