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
On 2014-02-02 14:44:17 +0900, Fujii Masao wrote:
On Sat, Feb 1, 2014 at 6:37 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-02-01 18:33:08 +0900, Fujii Masao wrote:
On Sat, Feb 1, 2014 at 6:09 PM, Andres Freund and...@2ndquadrant.com
wrote:
On 2014-02-01 16:47:47 +0900, Fujii
On Sun, Feb 2, 2014 at 11:06 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-02-02 14:44:17 +0900, Fujii Masao wrote:
On Sat, Feb 1, 2014 at 6:37 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-02-01 18:33:08 +0900, Fujii Masao wrote:
On Sat, Feb 1, 2014 at 6:09 PM, Andres
Add primary_slotname to recovery.conf.sample.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/0753bdb352270a03dec52bc959418fa82e9b07cc
Modified Files
--
src/backend/access/transam/recovery.conf.sample |6 ++
1 file changed, 6 insertions(+)
--
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/ ?
Clean up some sloppy coding in repl_gram.y.
Remove unused copy-and-pasted macro definitions, and improve formatting
of recently-added productions.
I got interested in this because buildfarm member protosciurus has been
crashing in bison repl_gram.y since commit 858ec11. It's a long shot
that
Add indexterm for functions pg_sleep_for and pg_sleep_until.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/c087e8cf3470081546c74b43e086e2b4d0a255d3
Modified Files
--
doc/src/sgml/func.sgml |6 ++
1 file changed, 6 insertions(+)
--
Sent via
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
Switch in psql_scan() must cover all lexer states (except backslash cases).
Oversight in commit f7559c0101afa33bfb4e104036ca46adac900111, which changed
UESCAPE lexing in psql. Per bug #9068 from Manuel Gómez.
Branch
--
REL9_3_STABLE
Details
---
Switch in psql_scan() must cover all lexer states (except backslash cases).
Oversight in commit f7559c0101afa33bfb4e104036ca46adac900111, which changed
UESCAPE lexing in psql. Per bug #9068 from Manuel Gómez.
Branch
--
master
Details
---
12 matches
Mail list logo
