Hello,
I'm very interested in pg_stat_statements usage, and I'm very happy to see
you adding plans to it.
Reading other pg_stat_statements threads on this forum, there are also activ
developments to add:
- planing duration,
- first date,
- last_update date,
- parameters for normalized queries,
- .
On Thu, Mar 22, 2018 at 11:16:30AM -0700, legrand legrand wrote:
> Reading other pg_stat_statements threads on this forum, there are also activ
> developments to add:
> - planing duration,
> - first date,
> - last_update date,
> - parameters for normalized queries,
> - ...
> as described in
> http:
On Thu, 2018-03-22 at 11:16 -0700, legrand legrand wrote:
> Reading other pg_stat_statements threads on this forum, there are
> also activ
> developments to add:
> - planing duration,
> - first date,
> - last_update date,
As I see it, planning duration, first date, and last update date would
be co
> I've created a draft patch that provides access to plans in a view
> called pg_stat_statements_plans.
++ I like it !
> There is no column that indicates whether the plan is "good" or "bad",
> because that is evident from the execution time of both plans and because
> that would require s
On Fri, 2018-04-06 at 13:57 -0700, legrand legrand wrote:
> At startup time there are 2 identical plans found in the view
> I thought it should have be only one: the "initial" one
> (as long as there is no "good" or "bad" one).
Yes, those are 'remnants' from the time where I had two columns, one
[...]
> I've taken a look at your patch. I agree that having a plan identifier
> would be great, but I'm not a big fan of the jumbling. That's a lot of
> hashing that needs to be done to decide wether two plans are
> essentially equivalent or not.
As there is no planid available yet in core, I reu
On Fri, Apr 20, 2018 at 6:34 PM, legrand legrand
wrote:
> It would be so helpfull if a planid was included in core Query / plan tree,
> it could be reused here in equal(), in explain commands,
> in pg_stat_activity, in pg_stat_statements ...
+1.
--
Robert Haas
EnterpriseDB: http://www.enterpris
On Fri, Apr 06, 2018 at 03:03:30PM +0200, Julian Markwort wrote:
> As I see it, planning duration, first date, and last update date would
> be columns added to the pg_stat_statements view, i.e. they are tracked
> for each kind of a (jumbled) query -- just as the good and bad plans,
> their associat
Hello
I notice latest patch version (v06) not applied after
da6f3e45ddb68ab3161076e120e7c32cfd46d1db commit in april. We have some
consensus with design of this feature?
I will mark CF entry as waiting on author
regards, Sergei
On Sat, Apr 7, 2018 at 1:03 AM, Julian Markwort
wrote:
> I've created a draft patch that provides access to plans in a view called
> pg_stat_statements_plans.
> There is no column that indicates whether the plan is "good" or "bad",
> because that is evident from the execution time of both plans
[ off topic for this patch, but as long as you mentioned switching
to C99 ]
Thomas Munro writes:
> + for(int j = 0; j < numPlans; j++)
> Can't declare a new variable here in C89.
As previously noted, that seems like a nice thing to allow ...
> + pgssPlan *planArray[numPlans];
> Can't use variab
On Mon, Aug 20, 2018 at 2:55 PM, Tom Lane wrote:
> Thomas Munro writes:
> As previously noted, that seems like a nice thing to allow ...
>
>> + pgssPlan *planArray[numPlans];
>> Can't use variable length arrays in C89.
>
> ... but I'm less excited about this one. Seems like a great opportunity
>
Thomas Munro writes:
> On Mon, Aug 20, 2018 at 2:55 PM, Tom Lane wrote:
>> Can we prevent that from being allowed,
>> if we start using -std=c99?
> -Werror=vla in GCC, apparently.
Ah, cool.
> Another problem with VLAs is that they aren't in C++ and last I heard
> they aren't ever likely to be
Hi,
On 2018-08-20 15:21:07 +1200, Thomas Munro wrote:
> On Mon, Aug 20, 2018 at 2:55 PM, Tom Lane wrote:
> > Thomas Munro writes:
> > ... but I'm less excited about this one. Seems like a great opportunity
> > for unexpected stack overflows, and thence at least the chance for
> > DOS-causing se
Andres Freund writes:
> On 2018-08-20 15:21:07 +1200, Thomas Munro wrote:
>> -Werror=vla in GCC, apparently.
> How about detecting support for that in our configure script and
> automatically using it? If we're uncomfortable with raising an error,
> let's at least raise a warning?
Yeah, we'd ce
Hello,
I'm very interested in pg_stat_statements usage, and I'm very happy to see
you adding plans to it.
Reading other pg_stat_statements threads on this forum, there are also activ
developments to add:
- planing duration,
- first date,
- last_update date,
- parameters for normalized queries,
- .
On Thu, Mar 22, 2018 at 11:16:30AM -0700, legrand legrand wrote:
> Reading other pg_stat_statements threads on this forum, there are also activ
> developments to add:
> - planing duration,
> - first date,
> - last_update date,
> - parameters for normalized queries,
> - ...
> as described in
> http:
On Thu, 2018-03-22 at 11:16 -0700, legrand legrand wrote:
> Reading other pg_stat_statements threads on this forum, there are
> also activ
> developments to add:
> - planing duration,
> - first date,
> - last_update date,
As I see it, planning duration, first date, and last update date would
be co
> I've created a draft patch that provides access to plans in a view
> called pg_stat_statements_plans.
++ I like it !
> There is no column that indicates whether the plan is "good" or "bad",
> because that is evident from the execution time of both plans and because
> that would require s
On Fri, 2018-04-06 at 13:57 -0700, legrand legrand wrote:
> At startup time there are 2 identical plans found in the view
> I thought it should have be only one: the "initial" one
> (as long as there is no "good" or "bad" one).
Yes, those are 'remnants' from the time where I had two columns, one
[...]
> I've taken a look at your patch. I agree that having a plan identifier
> would be great, but I'm not a big fan of the jumbling. That's a lot of
> hashing that needs to be done to decide wether two plans are
> essentially equivalent or not.
As there is no planid available yet in core, I reu
On Fri, Apr 20, 2018 at 6:34 PM, legrand legrand
wrote:
> It would be so helpfull if a planid was included in core Query / plan tree,
> it could be reused here in equal(), in explain commands,
> in pg_stat_activity, in pg_stat_statements ...
+1.
--
Robert Haas
EnterpriseDB: http://www.enterpris
Hello
I notice latest patch version (v06) not applied after
da6f3e45ddb68ab3161076e120e7c32cfd46d1db commit in april. We have some
consensus with design of this feature?
I will mark CF entry as waiting on author
regards, Sergei
On Sat, Apr 7, 2018 at 1:03 AM, Julian Markwort
wrote:
> I've created a draft patch that provides access to plans in a view called
> pg_stat_statements_plans.
> There is no column that indicates whether the plan is "good" or "bad",
> because that is evident from the execution time of both plans
[ off topic for this patch, but as long as you mentioned switching
to C99 ]
Thomas Munro writes:
> + for(int j = 0; j < numPlans; j++)
> Can't declare a new variable here in C89.
As previously noted, that seems like a nice thing to allow ...
> + pgssPlan *planArray[numPlans];
> Can't use variab
On Mon, Aug 20, 2018 at 2:55 PM, Tom Lane wrote:
> Thomas Munro writes:
> As previously noted, that seems like a nice thing to allow ...
>
>> + pgssPlan *planArray[numPlans];
>> Can't use variable length arrays in C89.
>
> ... but I'm less excited about this one. Seems like a great opportunity
>
Thomas Munro writes:
> On Mon, Aug 20, 2018 at 2:55 PM, Tom Lane wrote:
>> Can we prevent that from being allowed,
>> if we start using -std=c99?
> -Werror=vla in GCC, apparently.
Ah, cool.
> Another problem with VLAs is that they aren't in C++ and last I heard
> they aren't ever likely to be
Hi,
On 2018-08-20 15:21:07 +1200, Thomas Munro wrote:
> On Mon, Aug 20, 2018 at 2:55 PM, Tom Lane wrote:
> > Thomas Munro writes:
> > ... but I'm less excited about this one. Seems like a great opportunity
> > for unexpected stack overflows, and thence at least the chance for
> > DOS-causing se
Andres Freund writes:
> On 2018-08-20 15:21:07 +1200, Thomas Munro wrote:
>> -Werror=vla in GCC, apparently.
> How about detecting support for that in our configure script and
> automatically using it? If we're uncomfortable with raising an error,
> let's at least raise a warning?
Yeah, we'd ce
On Fri, Apr 06, 2018 at 03:03:30PM +0200, Julian Markwort wrote:
> As I see it, planning duration, first date, and last update date would
> be columns added to the pg_stat_statements view, i.e. they are tracked
> for each kind of a (jumbled) query -- just as the good and bad plans,
> their associat
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
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
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 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
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
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
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
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
>
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
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
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
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,
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
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
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
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
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
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
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 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
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
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
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
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
>
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
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
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
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,
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
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
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
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
62 matches
Mail list logo
