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
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,
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
> > boolean
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 union
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
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
>
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. t
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 testing the upgrade
>> path more w
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
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 already exists. But
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 cha
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
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
to
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 a
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 las
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
16 matches
Mail list logo
