Чи потрібен REINDEX після кластера CLUSTER?


12

Я розглядаю можливість використання кластера CLUSTER для впорядкування таблиці за індексом. Я розумію, що таке відтворення даних таблиці змушує всі існуючі індекси або розмиватися, або бути марними. Я бачив деякі вказівки, що після кластера потрібен REINDEX. Я знайшов інші посилання, які вказують на те, що CLUSTER робить REINDEX. В Офіційній Документації нічого не сказано про те, що REINDEX є частиною CLUSTER або не вимагає (Хоча це і передбачає запустити ANALYZE після CLUSTER)

Чи може хтось остаточно (тобто з якоюсь посиланням на офіційні документи) сказати, чи потрібно REINDEX після кластера чи ні?


2
Я не думаю, що це потрібно. clusterпереміщає рядки, тож доведеться все одно оновити інформацію про індекс.
a_horse_with_no_name

Так, але теорія в половині обговорень, які я знайшла, полягає в тому, що це призводить до розростання індексу.
ТРЕЙ

Відповіді:


12

Вам не потрібно переосмислювати, адже це CLUSTERефективно робить це за вас.

Більш конкретно, CLUSTERблокує вихідну таблицю, потім створює нову копію впорядкованої відповідно до цільового індексу. Він створює індекси на новій копії, потім замінює стару таблицю та індексує новою.

Зауважте, що це також стосується VACUUM FULLверсії 9.0+.

Якщо ви бачили дискусію, яка дозволяє припустити, що CLUSTERіндекси роздуття, це можуть бути люди, які вважають, що це CLUSTERпрацює як до 9.0 VACUUM FULL. Можливо, ви також бачите і неправильно читаєте дискусії, в яких згадується проміжок індексу, викликаний старою VACUUM FULLреалізацією та пропонуючи CLUSTERяк альтернативу .

Це мається на увазі в документації :

створюється тимчасова копія таблиці, яка містить дані таблиці в порядку індексу. Також створюються тимчасові копії кожного індексу в таблиці . Тому вам потрібно вільний простір на диску, щонайменше дорівнює сумі розміру таблиці та розмірів індексу

Що не говорить, але повинно, це те, що ці тимчасові копії потім замінюють оригінальну таблицю . (Смілива міна).


1
Чи є у вас посилання на те, що CLUSTER замінює індекси?
ТРЕЙ

1
@TREE Додано Документи прямо не кажуть вам, що тимчасова таблиця та індекси замінюють оригінали, але ви побачите, що це так, якщо ви насправді перегляньте каталог даних до / після CLUSTER або якщо ви вивчите вихідний код.
Крейг Рінгер

Я перевірив це, і принаймні мій тестовий сценарій розмір файлу індексу був зменшений. Але це лише один сценарій, і може бути багато змінних, які впливають на поведінку (кількість індексів, загальний розмір на диску тощо), тому я не можу довіряти простому тесту.
ТРЕЙ

1
@TREE Для абсолютної впевненості в розумінні поведінки за будь-яких можливих обставин вам потрібно буде прочитати вихідний код. Все , що я можу вам сказати, що я не знаю про будь-якій ситуації , в якій CLUSTERніяк НЕ перепишуть індекси, і експертизи фактичних файлів base/ясно покажуть нові relfilenodeс. Здається, ти хвилюєшся проблем, яких у тебе ще немає.
Крейг Рінгер

8

Я з цим a_horse_with_no_name: вам не потрібно відтворювати індекси. Крім того, що CLUSTERдокументація не згадує про це, ми також можемо додатково ознайомитися зі REINDEXсторінкою:

Існує кілька сценаріїв використання REINDEX:

  • Індекс став пошкодженим і більше не містить дійсних даних. Хоча теоретично цього ніколи не має відбуватися, на практиці індекси можуть пошкодитися через помилки програмного забезпечення або збої обладнання. REINDEX забезпечує метод відновлення.

  • Індекс став "роздутим", що він містить багато порожніх або майже порожніх сторінок. Це може статися з індексами B-дерева в PostgreSQL за певних шаблонів нечастого доступу. REINDEX надає спосіб зменшити споживання місця в індексі, написавши нову версію індексу без мертвих сторінок. Див. Розділ 23.2 для отримання додаткової інформації.

  • Ви змінили параметр пам’яті (наприклад, fillfactor) для індексу і хочете переконатися, що зміна набула повної сили.

  • Помилка складання індексу з опцією CONCURRENTLY, залишивши "недійсним" індекс. Такі індекси є марними, але REINDEX може бути зручним для їх відновлення. Зауважте, що REINDEX не виконає одночасне складання. Щоб скласти індекс, не втручаючись у виробництво, вам слід скинути індекс і повторно видати команду CREATE INDEX CONCURRENTLY.

Ясна річ, CLUSTERщо не потрапляє ні в один із цих випадків.

І в документах є невелике речення CLUSTER:

[під час кластеризації] Також створюються тимчасові копії кожного індексу в таблиці.

Це говорить про те, що так само, як і сама таблиця, індекси переробляються і під час процесу - таким чином роблячи повторне деіндексування марним.


Пропозиція, безумовно, є, і тестування, здається, підтверджує це. Мені буде краще покладатися на таку поведінку, якби документи фактично сказали, що індекси відтворені (постійно).
ТРЕ

2
Тут я бачу матеріали для патчу для doc. Посібник повинен бути більш чітким щодо відтворення індексів.
Erwin Brandstetter

В даний момент я підозрюю, що дияволи не хочуть офіційно документувати цю поведінку, оскільки вони не хочуть постійно бути прив’язаними до цієї реалізації.
ТРЕЙ

@TREE Є багато змін функцій між версіями і документи змінюються (в основному) відповідно. Імовірно, характеристики змінюються також :), тому я ніде не бачу краватки.
dezso

@dezso Правда, але вони будуть неохоче видаляти документально підтверджені функції. Зважаючи на якість документації в цілому, я все ж вважаю, що упущення такої поведінки навмисне.
ТРЕЙ

5

Знайдено посилання в розділі Відновлення місця на диску .

Якщо у вас є така таблиця, і вам потрібно повернути зайвий диск, який вона займає, вам потрібно буде використовувати VACUUM FULL або альтернативно CLUSTER або один із варіантів переписування таблиці ALTER TABLE. Ці команди переписують цілу нову копію таблиці та будують для неї нові індекси .


-3

Аналізуючи всі відповіді, на мою думку, правильний спосіб зробити це - повторно встановити ДО кластера. Оскільки в документації не вказано, чи робить кластер перевстановлення чи ні, а лише копія індексу, упорядкована чи ні, я думаю, що індексований індекс призведе до кращої кластерної таблиці. Після цього аналіз закінчить роботу. Вакуум, заповнений раніше всіх, здається марним, якщо тільки кластер та / або перевстановлення не звільняють мертві кортежі


Як вже говорилося в прийнятому відповіді, документація дійсно говорять , що індекси будуть відновлені, але тільки не на сторінці про команду CLUSTER.
ТРЕЙ

І те, CLUSTERі VACUUM FULLвиробляє абсолютно новий фізичний стіл - після нього просто не може бути жодного мертвого. Простір, що використовується старою копією, буде звільнено до кінця операції.
dezso

Справді. Він відтворить таблицю та всі індекси. Але у мене є сумніви щодо індексу, який використовує Кластер для впорядкування таблиці. Він буде перевстановлений спочатку або буде використовуватися для впорядкування таблиці, як є? А після цього індекс відтворюється? Тому що проблемний індекс може породжувати деякі проблеми ...
Ейслан Луїз Вендлінг
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.