Re:

Поиск
Список
Период
Сортировка
От Mark R. Dingee
Тема Re:
Дата
Msg-id 1147218706.6056.0.camel@elrond
обсуждение исходный текст
Ответ на Re:  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-admin
Tom,

Thanks for the advice.  I'll track it over the next couple weeks and see
what comes up.

Mark

On Tue, 2006-05-09 at 17:01 -0400, Tom Lane wrote:
> <mark.dingee@cox.net> writes:
> > I had an odd situation occur this morning with PGSQL 7.4 run on Red Hat Enterprise 4 (update 3) and could really
usesome wisdom.   
>
> > ...  Single postmaster running.
> > ...  vacuum full is run every night as part of a cron job
> > ...  At start, data files consume about 28 GB
> > ...  This morning I dropped the database and reloaded from current backup
> > ... New instance consumes about 6 GB
>
> > I can only assume that the database was not compacted, but I thought vacuum full performed that function along with
tuplemaintenance.  Can anyone expound on the problem and suggest a solution other than dropping and reloading the
database?
>
> The evidence is mostly gone now, but what I'd suggest is waiting a while
> to see if it bloats again, and if so finding out exactly *where* the
> bloat is.  Make some notes now about the sizes of your tables and
> indexes, and see what's getting larger.
>
> My guess offhand is that the problem is index bloat.  VACUUM FULL not
> only doesn't help much with that, it tends to make it worse.  If the
> database size is supposed to be fairly stable, you'd probably be better
> off with a maintenance regime that doesn't use VACUUM FULL but just
> plain VACUUM.  Make sure your FSM settings are high enough.
>
>             regards, tom lane


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

Предыдущее
От: "Chris Hoover"
Дата:
Сообщение: Terminating Idle Connections
Следующее
От: "Vadim Pestovnikov"
Дата:
Сообщение: Python os.system module handle errors