Re: unusual performance for vac following 8.2 upgrade

Our pgstats.stat file is 40M for 8.2, on 8.1 it was 33M. Our schema size
hasn't grown *that* much in the two weeks since we upgraded

I'm not sure if this sheds any more light on the situation, but in
scanning down through the process output from truss, it looks like the
first section of output was a large chunk of reads on pgstat.stat,
followed by a larger chunk of reads on the global directory and
directories under base - this whole section probably went on for a good
6-7 minutes, though I would say the reads on pgstat likely finished
within a couple of minutes or so. Following this there was a phase were
it did a lot of seeks and reads on files under pg_clog, and it was while
doing this (or perhaps it had finished whatever it wanted with clogs) it
dropped into the send()/SIGUSR1 loop that goes for another several minutes.

Kim

Tom Lane wrote:

>I wrote:
>
>
>>(2) Reconsider whether last-vacuum-time should be sent to the collector
>>unconditionally.
>>
>>
>
>Actually, now that I look, the collector already contains this logic:
>
> /*
> * Don't create either the database or table entry if it doesn't already
> * exist. This avoids bloating the stats with entries for stuff that is
> * only touched by vacuum and not by live operations.
> */
>
>and ditto for analyze messages. So my idea that the addition of
>last-vac-time was causing an increase in the statistics file size
>compared to 8.1 seems wrong.
>
>How large is your $PGDATA/global/pgstat.stat file, anyway?
>
> regards, tom lane
>
>---------------------------(end of broadcast)---------------------------
>TIP 6: explain analyze is your friend
>
>
>