Re: So why is EXPLAIN printing only *plan* time?
От | Tom Lane |
---|---|
Тема | Re: So why is EXPLAIN printing only *plan* time? |
Дата | |
Msg-id | 26286.1398633409@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: So why is EXPLAIN printing only *plan* time? (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: So why is EXPLAIN printing only *plan* time?
|
Список | pgsql-hackers |
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. 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
В списке pgsql-hackers по дате отправления: