Re: disk space usage enlarging despite vacuuming

Поиск
Список
Период
Сортировка
От Tzvetan Tzankov
Тема Re: disk space usage enlarging despite vacuuming
Дата
Msg-id 3EC8A9F8.3070000@noxis.net
обсуждение исходный текст
Ответ на Re: disk space usage enlarging despite vacuuming  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: disk space usage enlarging despite vacuuming  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
I did reindex which regained only 200-300 MB for all DBs (the situation
now is even more bad)
only the DB wallet, now is 1.3G !!! after full vacuum and reindexall

with relation_size from dbsize I got the following things for the system
tables, wich are not very frustraiting I think

pg_attribute 11M
pg_class 8M
pg_depend 2.5M
pg_type 1.5M

(if the returned value is bytes ;-)), I put only the tables that are
larger then 1M)

mine tables are also with normal sizes, the sume of them is about 100M
in this DB there are no large objects at all

what else can I check and how??

I should mention, that this is a situtation 2-3 weeks after a fresh
install with initdb

thanks in advance
ceco



Tom Lane wrote:
> Tzvetan Tzankov <ceco@noxis.net> writes:
>
>>I use debian package postgresql 7.3.2r1-2, it is set to vacuum every 5
>>hours and once weekly (sunday) vacuum -f, aditionally there are some
>>session tables which vacuum at 5 minutes, dispite this the disk usage
>>enlarges with 300-400MB for about 2 days and in sundey with the full vacuum
>>very few MB-s are recovered.
>
>
> There isn't enough info here to really tell what's going on; you need to
> look at the individual tables and indexes of the problem databases to
> see where the space is going.  (pg_class's relpages column will give
> you the right data, if you vacuum first.)
>
> A first guess is that the problem is index bloat, but that's really
> theorizing in advance of the data...
>
>             regards, tom lane
>
> .
>



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

Предыдущее
От: "Nigel J. Andrews"
Дата:
Сообщение: Re: implicit abort harmful?
Следующее
От: google@newtopia.com (Michael Pohl)
Дата:
Сообщение: plpgsql vs. SQL performance