Назад | Перейти на главную страницу

PostgreSQL: снижение производительности из-за раздутого индекса


Я использую PgSQL 8.1 в системе CentOS 4.4 (к сожалению, обновление не поддерживается).
Есть приложение Java, работающее поверх демона PgSQL, и мы должны переиндексировать базу данных каждые 2 месяца или около того. Также важно: база данных не растет.

Похоже, раздувание сейчас происходит быстрее, чем раньше, и это имеет тенденцию к увеличению.
Моя конфигурация доступна здесь, демон автоочистки включен и работает довольно часто: pastebin.com/RytNj7dK

Вы также можете найти вывод этого запроса wiki.postgresql.org/wiki/Show_database_bloat

Через 3 часа после выполнения переиндексации: http://pastebin.com/raw.php?i=75fybKyd
72 часа после выполнения переиндексации: http://pastebin.com/raw.php?i=89VKd7PC

Кто-нибудь знает, что я должен настроить, чтобы избавиться от этого растущего вздутия?

Спасибо за вашу помощь

PS: из-за системы защиты от спама мне пришлось удалить первые 2 префикса http: // для двух моих первых ссылок.

К сожалению, если у вас есть активная база данных (с большим количеством вставок / обновлений / удалений), вы воля опыт раздувания индекса - это просто факт жизни базы данных. Лучшее, что вы можете сделать, - это надеяться замедлить раздувание до точки, при которой интервалы переиндексации будут разумными.

Лучший совет, который я могу вам дать в этом отношении, - это перейти на более новую версию Postgres (8.3 или новее): это когда Postgres представил Кортежи только для кучи служба поддержки.
Прямо сейчас в вашей системе (8.1) ЛЮБОЙ обновление до строки эквивалентно удалению / вставке в отношении индекса, отсюда и раздувание индекса. 8.3 и более поздних версий не трогайте индекс, если это не нужно («Если строка все еще умещается на странице, на которой она находится»).

После обновления до версии Postgres с поддержкой HOT вы все равно можете столкнуться с раздуванием индекса, если ваш UPDATEs касаются индексированных столбцов, или если ваш UPDATEs существенно увеличить размер строки, так что ее нужно переместить на новую страницу, но такие ситуации должны быть относительно редкими, если ваша стратегия индексирования разумна, а ваши строки относительно статичны по размеру, поэтому проблема раздувания индекса должна быть меньше проблемы.

Некоторые дополнительные общие стратегии борьбы с раздуванием индекса:

  1. Индексы первичного ключа
    Тебе здесь не повезло - тебе нужно REINDEX и возьмите замок стола.
  2. Другие индексы
    • Опция 1: DROP и повторноCREATE Некритические индексы
      Это имеет то преимущество, что не блокирует таблицу, а недостаток в том, что индекс удаляется во время его перестроения.
    • Вариант 2: Index-Shuffle для критических индексов
      Вместо описанной выше процедуры удаления / создания сначала создайте новый index, затем, когда это будет сделано, удалите старый и переименуйте новый, чтобы он занял его место.
      Это имеет то преимущество, что таблица не блокируется, а исходный индекс остается работающим (хотя и раздутым). Основным недостатком является то, что вам нужно переименовать индекс, чтобы сохранить разумные соглашения об именах - дополнительный ручной шаг.