From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Greg Stark <gsstark(at)mit(dot)edu>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: log_duration and \timing times repeatably much higher than "Total runtime" from explain analyze |
Date: | 2003-10-10 23:56:39 |
Message-ID: | 877k3c6408.fsf@stark.dyndns.tv |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Stephan Szabo | 2003-10-11 00:23:31 | Re: Index/Foreign Key Question |
Previous Message | elein | 2003-10-10 23:53:55 | Re: int1? types? |