Re: log_duration and \timing times repeatably much higher

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, Greg Stark <gsstark(at)mit(dot)edu>, pgsql-general(at)postgresql(dot)org
Subject: Re: log_duration and \timing times repeatably much higher
Date: 2003-10-13 18:52:58
Message-ID: 871xth2cmt.fsf@stark.dyndns.tv
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Jan Wieck 2003-10-13 18:56:47 Re: "slicing" records
Previous Message Patrick Welche 2003-10-13 18:22:34 gborg cvs ?