* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > * Tom Lane (tgl@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
> >> 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.
As log_lock_waits only writes to the log file (a fact that I complained
about when we discussed its original implementation), I could see having
that info in EXPLAIN as useful. Of course, locks are also transient, so
this isn't as useful since it would only show under EXPLAIN. I'd still
love an option to have an async message sent to the client after lock
timeout which could let an end-user know that the query is waiting on a
lock.
> 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.
I agree with this.
Thanks,
Stephen
