Re: log_duration and \timing times repeatably much higher

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: log_duration and \timing times repeatably much higher
Дата
Msg-id 871xth2cmt.fsf@stark.dyndns.tv
обсуждение исходный текст
Ответ на Re: log_duration and \timing times repeatably much higher  (Alvaro Herrera <alvherre@dcc.uchile.cl>)
Список pgsql-general
Alvaro Herrera <alvherre@dcc.uchile.cl> writes:

> > > > 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.

As I posted separately that seems to be exactly where the time is being spent.
It take nearly a second simply for a plain old "explain" with no analyze.

> > > Could it be because of extremely large statistics settings for the
> > > tables involved?
> >
> > Which large statistics?  Does he more than the default number of
> > statistics buckets?
>
> I dunno, that's why I'm asking :-)  Just an idea.

This sounds like a good theory to me. But I can't find anything like that.
Perhaps some large statistic array being toasted and compressed?

What would I check for? Just looking in pg_statistic doesn't find anything
that stands out. The strangest lines to my eyes are the ones with the verbose
plan stuff in them, but there are similar lines on my working machine.

Is there any way to see what the values are set with
 ALTER TABLE ALTER column SET STATISTICS
?

Perhaps it should be listed in the \d output for the table?

--
greg

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

Предыдущее
От: "Matthew T. O'Connor"
Дата:
Сообщение: Re: Pgsql on Windows
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Pgsql on Windows