From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: So why is EXPLAIN printing only *plan* time? |
Date: | 2014-04-27 21:16:49 |
Message-ID: | 26286.1398633409@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)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
>> locks on the query's tables will be spent in the parser.
> Having a distinction between "time spent waiting on locks" (even
> just "waited on locks" as a boolean) would be very nice, imv. Having
> the time spent would be best, provided it doesn't add too much.
We've already got log_lock_waits. I'm not that eager to try to make
EXPLAIN print the same info, and even if I was, it would be a large and
invasive patch. The concern I had here was just that if an EXPLAIN does
get delayed by parse-time lock waits, it'd be nice if the printed times
added up to something approaching the observed runtime.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2014-04-27 21:25:18 | Re: So why is EXPLAIN printing only *plan* time? |
Previous Message | Andres Freund | 2014-04-27 21:15:51 | Re: Composite Datums containing toasted fields are a bad idea(?) |