Re: log_duration and \timing times repeatably much higher than "Total runtime" from explain analyze
От | Greg Stark |
---|---|
Тема | Re: log_duration and \timing times repeatably much higher than "Total runtime" from explain analyze |
Дата | |
Msg-id | 877k3c6408.fsf@stark.dyndns.tv обсуждение исходный текст |
Ответ на | Re: log_duration and \timing times repeatably much higher (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: log_duration and \timing times repeatably much higher than "Total runtime" from explain analyze
Re: log_duration and \timing times repeatably much higher than "Total runtime" from explain analyze |
Список | pgsql-general |
Bruce Momjian <pgman@candle.pha.pa.us> writes: > I know \timing counts the time to transfer the data to the client, and I > think log_duration also might have that timing added too. It does seem > like a long time to transfer data, though. a) Even when executing this query normally there's very little data. About 1-20 records. b) this is on an explain analyze which only returns the 37 records of the plan. I can't imagine that takes any real time. This is on a machine that's otherwise pretty much idle. It's a dual processor PII-900 and it used to perform fine. What's really strange is that some other queries perform fine but this one and a few others reliably takes this long and behaves this way under explain analyze. It's as if there's something specific about this query that triggers the delay. > > Total runtime: 316.19 msec > > (37 rows) > > > > Time: 1333.72 ms -- greg
В списке pgsql-general по дате отправления: