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,
- .
15 matches
Mail list logo
