I found a bit confusing, when planning time is greater total time, so
+1 for execution time.
On Thu, Apr 17, 2014 at 3:35 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
Where are we on this? I still see:
test= EXPLAIN ANALYZE SELECT 1;
On 04/17/2014 01:35 AM, Tom Lane wrote:
I'll go change it.
Thanks for fixing this. The new name Execution time is much clearer.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Mon, Feb 3, 2014 at 07:13:46PM -0500, Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
The problem I'm having with the way it stands now is that one would
reasonably expect that Total time is the total of all times counted
by EXPLAIN, including main plan execution time,
Bruce Momjian br...@momjian.us writes:
Where are we on this? I still see:
test= EXPLAIN ANALYZE SELECT 1;
QUERY PLAN
Result (cost=0.00..0.01
On Sun, Feb 2, 2014 at 11:13 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Geoghegan p...@heroku.com writes:
On Wed, Jan 29, 2014 at 1:10 PM, Robert Haas rh...@postgresql.org wrote:
Include planning time in EXPLAIN ANALYZE output.
Isn't it perhaps a little confusing that Planning time may well
On Mon, Feb 3, 2014 at 4:15 AM, Robert Haas robertmh...@gmail.com wrote:
I'm not really feeling a compelling need to change that. We've been
displaying total runtime - described exactly that way - for many
releases and it's surely is confusing to the novice that the time
reported can be much
Peter Geoghegan p...@heroku.com writes:
On Mon, Feb 3, 2014 at 4:15 AM, Robert Haas robertmh...@gmail.com wrote:
I'm not really feeling a compelling need to change that. We've been
displaying total runtime - described exactly that way - for many
releases and it's surely is confusing to the
* Tom Lane (t...@sss.pgh.pa.us) wrote:
The problem I'm having with the way it stands now is that one would
reasonably expect that Total time is the total of all times counted
by EXPLAIN, including main plan execution time, trigger firing time,
and now planning time. Since it is not, any
Peter Geoghegan p...@heroku.com writes:
On Wed, Jan 29, 2014 at 1:10 PM, Robert Haas rh...@postgresql.org wrote:
Include planning time in EXPLAIN ANALYZE output.
Isn't it perhaps a little confusing that Planning time may well
exceed Total runtime?
Perhaps s/Total runtime/Execution time/ ?
On Sun, Feb 2, 2014 at 8:13 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Perhaps s/Total runtime/Execution time/ ?
+1
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 03/02/14 09:44, Peter Geoghegan wrote:
On Sun, Feb 2, 2014 at 8:13 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Perhaps s/Total runtime/Execution time/ ?
+1
If the planning was ever made into a parallel process, then 'elapsed
time' would be less than the 'processor time'. So what does
Gavin Flower gavinflo...@archidevsys.co.nz writes:
Can I assume:
'Total runtime' is 'elapsed time'
and
'Execution time' is 'processor time'.
No. It's going to be elapsed time, either way.
In a parallel implementation, one would likely want both.
When and if we have that, we can argue
12 matches
Mail list logo
