On 01/29/2014 10:10 PM, Robert Haas wrote:
Committed with minor doc changes.
Thanks!
/Andreas
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Jan 29, 2014 at 3:13 PM, Andreas Karlsson wrote:
> On 01/29/2014 09:01 PM, Robert Haas wrote:
>> Cool. I propose adding one parameter rather than two to
>> ExplainOnePlan() and making it of type instr_time * rather than
>> passing an instr_time and a bool. If you don't want to include th
On 01/29/2014 09:01 PM, Robert Haas wrote:
Cool. I propose adding one parameter rather than two to
ExplainOnePlan() and making it of type instr_time * rather than
passing an instr_time and a bool. If you don't want to include the
planning time, pass NULL; if you do, pass a pointer to the instr_
On Wed, Jan 29, 2014 at 2:21 PM, Andreas Karlsson wrote:
> On 01/28/2014 09:39 PM, Tom Lane wrote:
>>
>> I'm for doing the measurement in ExplainOneQuery() and not printing
>> anything in code paths that don't go through there.
>
> Reading the discussion here and realizing that my last patch was w
On 01/28/2014 09:39 PM, Tom Lane wrote:
I'm for doing the measurement in ExplainOneQuery() and not printing
anything in code paths that don't go through there.
Reading the discussion here and realizing that my last patch was wrong I
am now in agreement with this. I have attached a patch which
Robert Haas writes:
> On Thu, Jan 9, 2014 at 11:45 PM, Tom Lane wrote:
>> Uh, no, wasn't my suggestion. Doesn't that design imply measuring *every*
>> planning cycle, explain or no? I was thinking more of just putting the
>> timing calls into explain.c.
> The problem is that you really can't d
On Thu, Jan 9, 2014 at 11:45 PM, Tom Lane wrote:
> Greg Stark writes:
>> On Thu, Jan 9, 2014 at 9:14 PM, Tom Lane wrote:
>>> In short then, I think we should just add this to EXPLAIN and be done.
>>> -1 for sticking the info into PlannedStmt or anything like that.
>
>> I'm confused. I thought I
On 01/13/2014 09:48 PM, Robert Haas wrote:
What I'm saying is that if EXPLAIN reports something that's labelled
"Planning Time", it should *be* the planning time, and not anything
else. When we retrieve a plan from cache, it would be sensible not to
report the planning time at all, and IMHO it w
On Mon, Jan 13, 2014 at 3:40 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Jan 13, 2014 at 3:23 PM, Tom Lane wrote:
>>> Meh. Why? This would only come into play for EXPLAIN EXECUTE stmtname.
>>> I don't think users would be surprised to see a report of minimal planning
>>> time for that
Robert Haas writes:
> On Mon, Jan 13, 2014 at 3:23 PM, Tom Lane wrote:
>> Meh. Why? This would only come into play for EXPLAIN EXECUTE stmtname.
>> I don't think users would be surprised to see a report of minimal planning
>> time for that. In fact, it might be a good thing, as it would make i
On Mon, Jan 13, 2014 at 3:23 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jan 9, 2014 at 11:45 PM, Tom Lane wrote:
>>> Uh, no, wasn't my suggestion. Doesn't that design imply measuring *every*
>>> planning cycle, explain or no? I was thinking more of just putting the
>>> timing calls i
Robert Haas writes:
> On Thu, Jan 9, 2014 at 11:45 PM, Tom Lane wrote:
>> Uh, no, wasn't my suggestion. Doesn't that design imply measuring *every*
>> planning cycle, explain or no? I was thinking more of just putting the
>> timing calls into explain.c.
> Currently the patch includes changes t
On 01/13/2014 09:06 PM, Stephen Frost wrote:
My thought, at least, was to always grab the planning time and then
provide it for explain and/or explain analyze, and then for re-plan
cases, indicate if a cached plan was returned, if a replan happened, and
if a replan happened, what the old plan tim
* Robert Haas (robertmh...@gmail.com) wrote:
> Currently the patch includes changes to prepare.c which is what seems
> odd to me. I think it'd be fine to say, hey, I can't give you the
> planning time in this EXPLAIN ANALYZE because I just used a cached
> plan and did not re-plan. But saying, hey
On Thu, Jan 9, 2014 at 11:45 PM, Tom Lane wrote:
> Greg Stark writes:
>> On Thu, Jan 9, 2014 at 9:14 PM, Tom Lane wrote:
>>> In short then, I think we should just add this to EXPLAIN and be done.
>>> -1 for sticking the info into PlannedStmt or anything like that.
>
>> I'm confused. I thought I
Greg Stark writes:
> On Thu, Jan 9, 2014 at 9:14 PM, Tom Lane wrote:
>> In short then, I think we should just add this to EXPLAIN and be done.
>> -1 for sticking the info into PlannedStmt or anything like that.
> I'm confused. I thought I was arguing to support your suggestion that
> the initial
On Thu, Jan 9, 2014 at 9:14 PM, Tom Lane wrote:
> In short then, I think we should just add this to EXPLAIN and be done.
> -1 for sticking the info into PlannedStmt or anything like that.
I'm confused. I thought I was arguing to support your suggestion that
the initial planning store the time in
Greg Stark writes:
> However I don't see the issue here. Two gettimeofday calls per query
> plan is not really going to hurt even on systems where it's slow.
I tend to agree with this, especially if the calls only occur when the
user asks for the information (ie, does an EXPLAIN rather than just
On Thu, Jan 9, 2014 at 1:50 PM, Stephen Frost wrote:
>> I do not think we want to always measure the time it took to
>> generate a plan due to slow clocks on some architectures. Also I
>> feel that such a patch would be more invasive.
>
> The slow-clock argument is really quite frustrating for tho
Andreas, Robert,
* Andreas Karlsson (andr...@proxel.se) wrote:
> A patch with updated documentation is attached.
Thanks for working on this!
> On 01/02/2014 04:08 AM, Robert Haas wrote:
> >I'm wondering whether the time should be stored inside the PlannedStmt
> >node instead of passing it around
A patch with updated documentation is attached.
On 01/02/2014 04:08 AM, Robert Haas wrote:
I'm wondering whether the time should be stored inside the PlannedStmt
node instead of passing it around separately. One possible problem
with the way you've done things here is that, in the case of a
prep
On 01/02/2014 04:08 AM, Robert Haas wrote:
I'm wondering whether the time should be stored inside the PlannedStmt
node instead of passing it around separately. One possible problem
with the way you've done things here is that, in the case of a
prepared statement, EXPLAIN ANALYZE will emit the tim
On Sat, Dec 28, 2013 at 11:32 PM, Andreas Karlsson wrote:
> New version of the patch with updated documentation and which does not
> display the planning time when the COSTS are off.
>
> I will add it to the next commitfest.
I'm wondering whether the time should be stored inside the PlannedStmt
n
New version of the patch with updated documentation and which does not
display the planning time when the COSTS are off.
I will add it to the next commitfest.
--
Andreas Karlsson
diff --git a/doc/src/sgml/perform.sgml b/doc/src/sgml/perform.sgml
new file mode 100644
index 2af1738..240a3d5
*** a
On 12/24/2013 05:09 AM, Robert Haas wrote:
Yeah. The alternatives seem to be:
1. Change a lot of regression tests. This would be a serious PITA,
not so much for the one-time cost as for every time we needed to
back-patch a regression test that includes explain output. -1.
2. Don't display th
On 12/24/2013 02:31 PM, Peter Eisentraut wrote:
On 12/23/13, 8:12 PM, Andreas Karlsson wrote:
A user asked in -performance[1] if there is a way to measure the
planning time.
log_planner_stats
Thanks for the suggestion, I will use that if I need to know the plan
times. But I do not think thi
On 12/23/13, 8:12 PM, Andreas Karlsson wrote:
> A user asked in -performance[1] if there is a way to measure the
> planning time.
log_planner_stats
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsq
On Mon, Dec 23, 2013 at 10:47 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Dec 23, 2013 at 9:54 PM, Andreas Karlsson wrote:
>>> Yeah, forgot to mention that we need some way to disable it in the tests.
>>> Either by not having it included in EXPLAIN or by adding an option to turn
>>> it
Robert Haas writes:
> On Mon, Dec 23, 2013 at 9:54 PM, Andreas Karlsson wrote:
>> Yeah, forgot to mention that we need some way to disable it in the tests.
>> Either by not having it included in EXPLAIN or by adding an option to turn
>> it off. Any suggestion on which would be preferable?
> I wo
On Mon, Dec 23, 2013 at 9:54 PM, Andreas Karlsson wrote:
> On 12/24/2013 03:33 AM, Tom Lane wrote:
>>
>> Andreas Karlsson writes:
>>>
>>> The patch does not include any changes to documentation or tests. I will
>>> fix that if people think this patch is useful.
>>
>>
>> I take it you've not tried
On 12/24/2013 03:33 AM, Tom Lane wrote:
Andreas Karlsson writes:
The patch does not include any changes to documentation or tests. I will
fix that if people think this patch is useful.
I take it you've not tried the regression tests with this.
Yeah, forgot to mention that we need some way t
On 23-12-2013 22:12, Andreas Karlsson wrote:
> A user asked in -performance[1] if there is a way to measure the
> planning time. Other than measuring it in the client I do not think
> there is so I quickly hacked a patched which adds "Planning time" to the
> outputs of EXPLAIN and EXPLAIN ANALYZE.
Andreas Karlsson writes:
> The patch does not include any changes to documentation or tests. I will
> fix that if people think this patch is useful.
I take it you've not tried the regression tests with this.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pg
Hi,
A user asked in -performance[1] if there is a way to measure the
planning time. Other than measuring it in the client I do not think
there is so I quickly hacked a patched which adds "Planning time" to the
outputs of EXPLAIN and EXPLAIN ANALYZE.
Is this something useful? I think it is, s
34 matches
Mail list logo
