On 8 March 2012 14:44, Tom Lane wrote:
> I thought the proposal was to add it to (1) pg_stat_statement and (2)
> EXPLAIN, both of which are not in the normal code execution path.
> pg_stat_statement is already a drag on a machine with slow gettimeofday,
> but it's not clear why users of it would t
Peter Geoghegan writes:
> On 8 March 2012 13:09, Robert Haas wrote:
>> Then again, considering that gettimeofday is kinda
>> expensive, I suppose that would have to be optional if we were to have
>> it at all.
> +1. I'm not opposed to having such a mechanism, but it really ought to
> impose exa
On 8 March 2012 13:09, Robert Haas wrote:
> Then again, considering that gettimeofday is kinda
> expensive, I suppose that would have to be optional if we were to have
> it at all.
+1. I'm not opposed to having such a mechanism, but it really ought to
impose exactly no overhead on the common case
On Wed, Mar 7, 2012 at 9:59 PM, Fujii Masao wrote:
>> I'd like to have the planning time in a number of other places as
>> well, such as EXPLAIN, and maybe statistics views.
>
> +1 for EXPLAIN. But which statistics views are in your mind?
I don't know. I'm not sure if it's interesting to be able
On Thu, Mar 8, 2012 at 1:07 AM, Tom Lane wrote:
> Fujii Masao writes:
>> In the patch, I didn't change the column name "total_time" meaning
>> the time spent in the executor because of the backward compatibility.
>> But once new column "plan_time" is added, "total_time" is confusing and
>> ISTM i
On Thu, Mar 8, 2012 at 12:39 AM, Robert Haas wrote:
> On Wed, Mar 7, 2012 at 6:45 AM, Fujii Masao wrote:
>> pg_stat_statements is basically very helpful to find out slow queries.
>> But since it doesn't report the time spent in the planner, we cannot
>> find out slow queries which take most time
On Wed, Mar 7, 2012 at 8:07 AM, Tom Lane wrote:
> Fujii Masao writes:
>> In the patch, I didn't change the column name "total_time" meaning
>> the time spent in the executor because of the backward compatibility.
>> But once new column "plan_time" is added, "total_time" is confusing and
>> ISTM i
Fujii Masao writes:
> In the patch, I didn't change the column name "total_time" meaning
> the time spent in the executor because of the backward compatibility.
> But once new column "plan_time" is added, "total_time" is confusing and
> ISTM it should be renamed...
Well, if we were tracking plann
On Wed, Mar 7, 2012 at 6:45 AM, Fujii Masao wrote:
> pg_stat_statements is basically very helpful to find out slow queries.
> But since it doesn't report the time spent in the planner, we cannot
> find out slow queries which take most time to do query planning, from
> pg_stat_statements. Is there
On Wed, Mar 7, 2012 at 9:00 PM, Simon Riggs wrote:
> On Wed, Mar 7, 2012 at 11:45 AM, Fujii Masao wrote:
>
>> Attached patch extends pg_stat_statements so that it reports the
>> planning time. Thought?
>
> If we successfully aggregate SQL in the current patch then this might
> be useful as well.
On Wed, Mar 7, 2012 at 11:45 AM, Fujii Masao wrote:
> Attached patch extends pg_stat_statements so that it reports the
> planning time. Thought?
If we successfully aggregate SQL in the current patch then this might
be useful as well. Until we do that it's not much use.
--
Simon Riggs
Hi,
pg_stat_statements is basically very helpful to find out slow queries.
But since it doesn't report the time spent in the planner, we cannot
find out slow queries which take most time to do query planning, from
pg_stat_statements. Is there any reason why pg_stat_statements doesn't
collect the p
12 matches
Mail list logo
