On Wed, Mar 7, 2012 at 9:59 PM, Fujii Masao masao.fu...@gmail.com 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
On 8 March 2012 13:09, Robert Haas robertmh...@gmail.com 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
Peter Geoghegan pe...@2ndquadrant.com writes:
On 8 March 2012 13:09, Robert Haas robertmh...@gmail.com 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,
On 8 March 2012 14:44, Tom Lane t...@sss.pgh.pa.us 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
On Wed, Mar 7, 2012 at 11:45 AM, Fujii Masao masao.fu...@gmail.com 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.
--
On Wed, Mar 7, 2012 at 9:00 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, Mar 7, 2012 at 11:45 AM, Fujii Masao masao.fu...@gmail.com wrote:
Attached patch extends pg_stat_statements so that it reports the
planning time. Thought?
If we successfully aggregate SQL in the current patch
On Wed, Mar 7, 2012 at 6:45 AM, Fujii Masao masao.fu...@gmail.com 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
Fujii Masao masao.fu...@gmail.com 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
On Wed, Mar 7, 2012 at 8:07 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Fujii Masao masao.fu...@gmail.com 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
On Thu, Mar 8, 2012 at 12:39 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Mar 7, 2012 at 6:45 AM, Fujii Masao masao.fu...@gmail.com 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
On Thu, Mar 8, 2012 at 1:07 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Fujii Masao masao.fu...@gmail.com 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
11 matches
Mail list logo
