Re: log_duration and \timing times repeatably much higher

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: log_duration and \timing times repeatably much higher
Дата
Msg-id 200310111522.h9BFMac05238@candle.pha.pa.us
обсуждение исходный текст
Ответ на Re: log_duration and \timing times repeatably much higher than "Total runtime" from explain analyze  (Martijn van Oosterhout <kleptog@svana.org>)
Ответы Re: log_duration and \timing times repeatably much higher
Список pgsql-general
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
> Planning time?

Uh, I thought the actual number reported by EXPLAIN ANALYZE includes
parse/plan times, but now that you mention it, if it is timing things
inside the executor, it might be just executor times.

Looking at explain.c, it is only timing the executor part in
ExplainOnePlan().  The planner() call is outside that loop, so it must
be parse/plan, though that seems like a lot of time spent in that area.

---------------------------------------------------------------------------

>
> On Fri, Oct 10, 2003 at 07:56:39PM -0400, Greg Stark wrote:
> >
> > 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
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 3: if posting/reading through Usenet, please send an appropriate
> >       subscribe-nomail command to majordomo@postgresql.org so that your
> >       message can get through to the mailing list cleanly
>
> --
> Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> > "All that is needed for the forces of evil to triumph is for enough good
> > men to do nothing." - Edmond Burke
> > "The penalty good people pay for not being interested in politics is to be
> > governed by people worse than themselves." - Plato
-- End of PGP section, PGP failed!

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

В списке pgsql-general по дате отправления:

Предыдущее
От: Jeff
Дата:
Сообщение: Re: backend exit mystery
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: log_duration and \timing times repeatably much higher