From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Greg Stark <stark(at)mit(dot)edu> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Andreas Karlsson <andreas(at)proxel(dot)se>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Planning time in explain/explain analyze |
Date: | 2014-01-10 04:45:24 |
Message-ID: | 26398.1389329124@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greg Stark <stark(at)mit(dot)edu> writes:
> On Thu, Jan 9, 2014 at 9:14 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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 the cached plan and explain
> should output the time the original planning took.
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2014-01-10 04:51:42 | Re: Standalone synchronous master |
Previous Message | Bruce Momjian | 2014-01-10 04:07:52 | Re: Bogus error handling in pg_upgrade |