Re: Hide 'Execution time' in EXPLAIN (COSTS OFF) - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Hide 'Execution time' in EXPLAIN (COSTS OFF)
Date
Msg-id 1351f76f-69a4-4257-91c2-9382e2a6dc22@email.android.com
Whole thread Raw
In response to Re: Hide 'Execution time' in EXPLAIN (COSTS OFF)  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Hide 'Execution time' in EXPLAIN (COSTS OFF)  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On June 3, 2014 9:40:27 PM CEST, Robert Haas <robertmhaas@gmail.com> wrote:
>On Tue, Jun 3, 2014 at 3:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Andres Freund <andres@2ndquadrant.com> writes:
>>> In 9.4. COSTS OFF for EXPLAIN prevents 'Planning time' to be
>>> printed. Should we perhaps do the same for 'Execution time'? That'd
>make
>>> it possible to use EXPLAIN (ANALYZE, COSTS OFF, TIMING OFF) in
>>> regression tests.
>>
>>> Currently the output for that is:
>>> postgres=# EXPLAIN (ANALYZE, TIMING OFF, COSTS OFF) SELECT 1;
>>>            QUERY PLAN
>>> --------------------------------
>>>  Result (actual rows=1 loops=1)
>>>  Total runtime: 0.035 ms
>>> (2 rows)
>>
>>> Leaving off the total runtime doesn't seem bad to me.
>>
>> It seems a little weird to call it a "cost" ... but maybe that
>> ship has sailed given how we're treating the planning-time item.
>
>Maybe we could make it be controlled by TIMING.  Seems like it fits
>well-enough there.

Don't think that fits well - TIMING imo is about reducing the timing overhead. But the server side total time is still
interesting.I only thought about tacking it onto COST because that already is pretty much tailored for regression test
usage.C.F. disabling the planning time.
 

Andres

-- 
Please excuse brevity and formatting - I am writing this on my mobile phone.

Andres Freund                       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Hide 'Execution time' in EXPLAIN (COSTS OFF)
Next
From: Tom Lane
Date:
Subject: Re: Memory deallocation after calling cast function