Re: pg_statistic_relid_att_index

Поиск
Список
Период
Сортировка
От scott.marlowe
Тема Re: pg_statistic_relid_att_index
Дата
Msg-id Pine.LNX.4.33.0306250325260.29859-100000@css120.ihs.com
обсуждение исходный текст
Ответ на pg_statistic_relid_att_index  (Jean-Christophe ARNU (JX) <arnu@paratronic.fr>)
Ответы Re: pg_statistic_relid_att_index  (Jean-Christophe ARNU (JX) <arnu@paratronic.fr>)
Список pgsql-general
Drop and recreate the index is your only solution given the constraints
you have.

On Wed, 25 Jun 2003, Jean-Christophe ARNU wrote:

> Hi all,
>     I've a problem with the pg_statistic_relid_att_index system index. The server
> version is 7.1.3 (so reindex is not available). This database is heavily
> updated,inserted,deleted and thus vacuumed. Since 1,5 year it runned perfectly
> but since the beginning of the we've got slow select. In many case, as the
> system goes slow, it often a question of table size. So I looked at the oid
> sizes in my data directory and the filenode corresponding to the
> pg_statistic_relid_att_index get about 87MB of my disk whereas other object
> remains quite small. I presume this index is not cleaned while vacuuming
> pg_statistic table (with or without analyze).  My problem is a performance
> problem. I would avoid to upgrade database to 7.3 (some upgrade would be done
> soon and I do not really have time to spend now for such a task) and I would
> like to make this index slimmer as possible to get the performance back (for
> this database speed is a critical factor).
>
>     Thanks in advance for any help/hints :)
>
>


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

Предыдущее
От: Sven Köhler
Дата:
Сообщение: Re: [BUG?] table inhiritance violates primary key
Следующее
От: Jean-Christophe ARNU (JX)
Дата:
Сообщение: Re: pg_statistic_relid_att_index