Re: after vacuum, db is still "growing" :(

Поиск
Список
Период
Сортировка
От Rafael Martinez Guerrero
Тема Re: after vacuum, db is still "growing" :(
Дата
Msg-id 1134118844.19512.68.camel@bbking.uio.no
обсуждение исходный текст
Ответ на after vacuum, db is still "growing" :(  (gabor <gabor@nekomancer.net>)
Ответы Re: after vacuum, db is still "growing" :(  (Martijn van Oosterhout <kleptog@svana.org>)
Список pgsql-general
On Fri, 2005-12-09 at 08:45, gabor wrote:
[...........]
>
> are there any cases, where a normal vacuum is unable to reclaim some
> space

Hello

We have det same problem in some databases running 7.4.8. Having
max_fsm_pages and max_fsm_relations properly configurated does not help.

It looks like this happens in tables with data that is updated/deleted
very often and that the files growing are the ones for the indexes, when
using B-trees.

We noticed this problem when a clean restore of a database used much
less space and the big different were in the indexes files.

In a busy 24/7 database a reindex of the indexes in a big table is not
a solution because using an ACCESS EXCLUSIVE lock for a 'long' time will
block access to data.

I have not tested if the only problem is that we use more and more space
or if performance also gets worst.

Is it possible to fix this, do we have any plans, is it better with 8.0
or 8.1?

Thanks in advance for your answers :)
--
Rafael Martinez, <r.m.guerrero@usit.uio.no>
Center for Information Technology Services
University of Oslo, Norway

PGP Public Key: http://folk.uio.no/rafael/

Вложения

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

Предыдущее
От: Richard Huxton
Дата:
Сообщение: Re: How efficient is select currval?
Следующее
От: "Greg Sabino Mullane"
Дата:
Сообщение: GnuPG / PGP signed MD5 and SHA1 checksums for PostgreSQL 8.1.0