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? I'm aware that we aren't super clear on the
accounting here generally, as with
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-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
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
Include planning time in EXPLAIN ANALYZE output.
This doesn't work for prepared queries, but it's not too easy to get
the information in that case and there's some debate as to exactly
what the right thing to measure is, so just do this for now.
Andreas Karlsson, with slight doc changes by me.
