On Sun, Apr 27, 2014 at 1:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
... and not, in particular, parse analysis or rewrite time?
I think breaking those out would be a good idea. Especially rewrite time.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Robert Haas robertmh...@gmail.com writes:
On Sun, Apr 27, 2014 at 1:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
... and not, in particular, parse analysis or rewrite time?
I think breaking those out would be a good idea. Especially rewrite time.
Rewrite time seems generally negligible in
On Mon, Apr 28, 2014 at 11:36 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, Apr 27, 2014 at 1:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
... and not, in particular, parse analysis or rewrite time?
I think breaking those out would be a good idea.
On 04/27/2014 07:07 PM, Tom Lane wrote:
Rewrite timing could easily be captured by EXPLAIN since that call
is done within ExplainQuery(). Parse analysis isn't, but we could
imagine having transformExplainStmt() time the operation and stick
the result into a new field in struct ExplainStmt.
I'm
Andreas Karlsson andr...@proxel.se writes:
On 04/27/2014 07:07 PM, Tom Lane wrote:
Rewrite timing could easily be captured by EXPLAIN since that call
is done within ExplainQuery(). Parse analysis isn't, but we could
imagine having transformExplainStmt() time the operation and stick
the
Tom Lane-2 wrote
Or we could add them into
just the first planning-time printout, though that might also be
misleading.
If you are going to show a number for these steps, which seems like a good
idea, then this seems like a reasonable option in the face of this
situation.
Basically two
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I'd been a bit suspicious of the recent patch to add $SUBJECT
without the other pre-execution components, but it just now
occurred to me that there's at least one reason why this might
be a significant omission: any delay caused by waiting to acquire
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I'd been a bit suspicious of the recent patch to add $SUBJECT
without the other pre-execution components, but it just now
occurred to me that there's at least one reason why this might
be a significant omission:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I'd been a bit suspicious of the recent patch to add $SUBJECT
without the other pre-execution components, but it just now
occurred to me that there's at least one reason
Tom,
I'd been a bit suspicious of the recent patch to add $SUBJECT
without the other pre-execution components, but it just now
occurred to me that there's at least one reason why this might
be a significant omission: any delay caused by waiting to acquire
locks on the query's tables will be
On 27 April 2014 22:38, Tom Lane Wrote:
... and not, in particular, parse analysis or rewrite time?
I'd been a bit suspicious of the recent patch to add $SUBJECT without
the other pre-execution components, but it just now occurred to me that
there's at least one reason why this might be a
11 matches
Mail list logo
