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?  (Stephen Frost <sfrost@snowman.net>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Composite Datums containing toasted fields are a bad idea(?)
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: So why is EXPLAIN printing only *plan* time?