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
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
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
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
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
>
[ 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 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
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 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
[...]
> 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, 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 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 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
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:
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,
- .
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
31 matches
Mail list logo
