On Thu, Mar 9, 2017 at 2:58 AM, Stephen Frost wrote:
> Ashutosh,
>
> * Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote:
>> On Tue, Mar 7, 2017 at 9:23 PM, Stephen Frost wrote:
>> > I'm going through these with an eye towards committing them soon. I've
>> > already adjusted some of the doc
Ashutosh,
* Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote:
> On Tue, Mar 7, 2017 at 9:23 PM, Stephen Frost wrote:
> > I'm going through these with an eye towards committing them soon. I've
> > already adjusted some of the documentation and comments per our earlier
> > discussion
>
> Th
On Tue, Mar 7, 2017 at 9:23 PM, Stephen Frost wrote:
> Ashutosh,
>
> * Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote:
>> Here are patches for follwing
>> 1. pg_explain_plan_time_v3 adds SUMMARY option which behaves as:
>> SUMMARY when ON prints planning time. With ANALYZE ON, it also prin
Ashutosh,
* Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote:
> Here are patches for follwing
> 1. pg_explain_plan_time_v3 adds SUMMARY option which behaves as:
> SUMMARY when ON prints planning time. With ANALYZE ON, it also prints
> execution time. When user explicitly uses SUMMARY OFF, it
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Wed, Jan 4, 2017 at 7:59 PM, Ashutosh Bapat
> wrote:
> > Here are patches for following
>
> Those patches have received no code-level reviews, so moved to CF 2017-03.
Yeah, I've been rather busy with email and bug fixes, but this is still
On Wed, Jan 4, 2017 at 7:59 PM, Ashutosh Bapat
wrote:
> Here are patches for following
Those patches have received no code-level reviews, so moved to CF 2017-03.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.p
Andres Freund writes:
> On 2016-12-28 10:29:48 -0500, Tom Lane wrote:
>> How about just saying that the existing TIMING option turns this on,
> I don't like this much - I'd like (as previously stated in [1]) to be
> able to have an actual EXPLAIN ANALYZE (COSTS off, TIMING OFF) in tests
> because
On 2016-12-28 10:29:48 -0500, Tom Lane wrote:
> How about just saying that the existing TIMING option turns this on,
> if it's specified without ANALYZE? Right now that combination draws
> an error:
>
> regression=# explain (timing on) select 1;
> ERROR: EXPLAIN option TIMING requires
On Wed, Jan 4, 2017 at 8:24 PM, Stephen Frost wrote:
> Ashutosh,
>
> I realize you were replying to yourself, but you probably didn't need to
> include the entire thread below or to top-post.
Sorry, that was unintentional.
>
> * Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote:
>> 1. pg_ex
Ashutosh,
I realize you were replying to yourself, but you probably didn't need to
include the entire thread below or to top-post.
* Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote:
> 1. pg_explain_plan_time_v3 adds SUMMARY option which behaves as:
> SUMMARY when ON prints planning time. W
Here are patches for follwing
1. pg_explain_plan_time_v3 adds SUMMARY option which behaves as:
SUMMARY when ON prints planning time. With ANALYZE ON, it also prints
execution time. When user explicitly uses SUMMARY OFF, it does not
print planning and execution time (even when ANALYZE is ON). By
def
On Wed, Dec 28, 2016 at 10:55 PM, Stephen Frost wrote:
> Tom,
>
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Stephen Frost writes:
>> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> >> I think it's an awful choice of name; it has nothing to do with either
>> >> the functionality or the printed name of
On Wed, Dec 28, 2016 at 10:30 PM, Tom Lane wrote:
> Stephen Frost writes:
>> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>>> I think it's an awful choice of name; it has nothing to do with either
>>> the functionality or the printed name of the field.
>
>> As an example, we might some day wish to incl
On Wed, Dec 28, 2016 at 8:41 PM, Stephen Frost wrote:
> * Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote:
>> >> One can use this option as
>> >> postgres=# explain (summary on) select * from pg_class c, pg_type t
>> >> where c.reltype = t.oid;
>> >> QUERY PL
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> I think it's an awful choice of name; it has nothing to do with either
> >> the functionality or the printed name of the field.
>
> > As an example, we might some day wish to inclu
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> I think it's an awful choice of name; it has nothing to do with either
>> the functionality or the printed name of the field.
> As an example, we might some day wish to include a summary of buffer
> information at the bottom too wh
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote:
> >>> I am not sure whether using *summary* to print just planning time is a
> >>> good idea. Another option could be SUMMARY_PLAN_TIME.
>
> > Using 'summary' seems
Tom Lane wrote:
> How about just saying that the existing TIMING option turns this on,
> if it's specified without ANALYZE? Right now that combination draws
> an error:
>
> regression=# explain (timing on) select 1;
> ERROR: EXPLAIN option TIMING requires ANALYZE
>
> so there's no
Stephen Frost writes:
> * Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote:
>>> I am not sure whether using *summary* to print just planning time is a
>>> good idea. Another option could be SUMMARY_PLAN_TIME.
> Using 'summary' seems entirely reasonable to me,
I think it's an awful choice
* Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote:
> >> One can use this option as
> >> postgres=# explain (summary on) select * from pg_class c, pg_type t
> >> where c.reltype = t.oid;
> >> QUERY PLAN
> >> -
>>
>> One can use this option as
>> postgres=# explain (summary on) select * from pg_class c, pg_type t
>> where c.reltype = t.oid;
>> QUERY PLAN
>> --
>> Hash Join (cost=17.12..35.70 rows=319
On Wed, Dec 28, 2016 at 02:08:55PM +0100, Michael Banck wrote:
> On Tue, Dec 27, 2016 at 09:26:21AM -0500, Stephen Frost wrote:
> > * Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote:
> > > We report planning and execution time when EXPLAIN ANALYZE is issued.
> > > We do not have facility to
On Tue, Dec 27, 2016 at 09:26:21AM -0500, Stephen Frost wrote:
> * Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote:
> > We report planning and execution time when EXPLAIN ANALYZE is issued.
> > We do not have facility to report planning time as part EXPLAIN
> > output. In order to get the pl
On Tue, Dec 27, 2016 at 1:27 PM, Ashutosh Bapat
wrote:
> Hi,
> We report planning and execution time when EXPLAIN ANALYZE is issued.
> We do not have facility to report planning time as part EXPLAIN
> output. In order to get the planning time, one has to issue EXPLAIN
> ANALYZE which involves exec
Ashutosh,
* Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote:
> We report planning and execution time when EXPLAIN ANALYZE is issued.
> We do not have facility to report planning time as part EXPLAIN
> output. In order to get the planning time, one has to issue EXPLAIN
> ANALYZE which involv
Hi,
We report planning and execution time when EXPLAIN ANALYZE is issued.
We do not have facility to report planning time as part EXPLAIN
output. In order to get the planning time, one has to issue EXPLAIN
ANALYZE which involves executing the plan, which is unnecessary.
We report planning and exec
26 matches
Mail list logo