Re: Slow Restoration of a template1 Database (ALTER GROUP)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Slow Restoration of a template1 Database (ALTER GROUP)
Дата
Msg-id 9639.1107892769@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Slow Restoration of a template1 Database (ALTER GROUP)  ("Ben Young" <Ben.Young@etrials.com>)
Список pgsql-performance
"Ben Young" <Ben.Young@etrials.com> writes:
> template1=# VACUUM FULL VERBOSE pg_group;
> INFO:  --Relation pg_catalog.pg_group--
> INFO:  Pages 124: Changed 1, reaped 124, Empty 0, New 0; Tup 4: Vac 966, Keep/VTL 0/0, UnUsed 156, MinLen 92, MaxLen
136;Re-using: Free/Avail. Space 1008360/1008360; EndEmpty/Avail. Pages 0/124. 
>     CPU 0.01s/0.00u sec elapsed 0.07 sec.
> INFO:  Index pg_group_name_index: Pages 19072; Tuples 4: Deleted 966.
                                          ^^^^^
>     CPU 1.51s/0.25u sec elapsed 17.19 sec.
> INFO:  Index pg_group_sysid_index: Pages 4313; Tuples 4: Deleted 966.
                                           ^^^^
>     CPU 0.48s/0.04u sec elapsed 6.06 sec.

Whoa.  Can you say "index bloat"?

I think that the only way to fix this is to REINDEX pg_group, which IIRC
in 7.3 requires stopping the postmaster and doing it in a standalone
backend (check the REINDEX reference page for details).  Make sure the
toast table gets reindexed too, as its index is oversized as well.
(Recent PG versions will automatically reindex the toast table when you
reindex its parent table, but I forget whether 7.3 did so; you might
have to explicitly "reindex pg_toast.pg_toast_1261".)

            regards, tom lane

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Slow Restoration of a template1 Database (ALTER GROUP)
Следующее
От: "Ben Young"
Дата:
Сообщение: Re: Slow Restoration of a template1 Database (ALTER GROUP)