Чи рекомендується регулярний аналіз ВАКУУМУ відповідно до пункту 9.1?

Я використовую PostgreSQL 9.1 в Ubuntu. Заплановано VACUUM ANALYZEще рекомендуються, або автовакуумінг досить , щоб піклуватися про всіх потребах?

Якщо відповідь "це залежить", то:

• У мене є велика база даних (розмір стисненого дампа розміром 30 Гб, каталог даних 200 ГБ)
• Я роблю ETL в базу даних, імпортуючи близько 3 мільйонів рядків на тиждень
• Таблиці з найчастішими змінами успадковуються з головної таблиці без даних у головній таблиці (дані розподіляються за тижнями)
• Я створюю щогодинний перелік, а звідти щоденні, щотижневі та щомісячні звіти

Я запитую, оскільки заплановане VACUUM ANALYZEвпливає на мою звітність. Він працює більше 5 годин, і мені довелося вбивати його двічі на цьому тижні, оскільки це впливало на регулярний імпорт бази даних. check_postgresне повідомляє про будь-яку істотну появу в базі даних, тому це насправді не проблема.

Від документів, autovacuum також повинен подбати про обертання ідентифікатора транзакції. Питання стоїть: мені ще потрібно VACUUM ANALYZE?

VACUUM потрібен лише для оновлених або видалених рядків у не тимчасових таблицях. Очевидно, ви робите багато ВСТАВКІВ, але з опису не очевидно, що ви також робите багато ОНОВЛЕННЯ або УДАЛЕННЯ.

Ці операції можна відстежувати за допомогою pg_stat_all_tablesпредставлення даних, зокрема, n_tup_updта n_tup_delстовпців. Крім того, ще більше до речі, є n_dead_tupстовпець, який повідомляє за таблицею, скільки рядків потрібно пилососити. (див. Моніторинг статистики в документі щодо функцій та поглядів, пов’язаних зі збором статистики).

Можливою стратегією у вашому випадку буде придушити запланований VACUUM, слідкуючи за цим переглядом і перевіряючи, за якими таблицями n_dead_tupістотно йде. Потім застосуйте агресивний VACUUM лише до цих таблиць. Це буде виграшним, якщо є великі таблиці, рядки яких ніколи не видаляються та не оновлюються, а агресивний VACUUM дійсно необхідний лише для менших таблиць.

Але продовжуйте працювати АНАЛІЗ, щоб оптимізатор завжди мав свіжу статистику.

Я не бачу у вашому питанні нічого, що autovacuumб не подбало. Це багато в чому залежить від структури вашої письменницької діяльності . Ви згадуєте 3 мільйони нових рядків на тиждень, але INSERT(або COPY) зазвичай не створюють проміжки таблиці та індексу. (слід autovacuumлише подбати про статистику стовпців , карту видимості та деякі незначні завдання). UPDATEі DELETEє домінуючою причиною розкриття таблиці та індексу, особливо при націлюванні на випадкові рядки. Я нічого не бачу у вашому запитанні.

autovacuumпройшов довгий шлях і робить велику роботу в Postgres 9.1 або пізнішої версії. Я б подивився на autovacuumналаштування . Якщо пилосос, як правило, не заважає вашому робочому навантаженню, також ознайомтеся з "Вакуумним затримкою на основі витрат" . Ручне пилосос має бути рідкісним винятком.

Якщо у вас є безліч випадкових UPDATEс, ви можете встановити FILLFACTORщось нижче 100, щоб дозволити оновлення HOT відразу та зменшити потребу в VACUUM. Більше про оновлення HOT:

• Надлишки даних у операторах оновлення

Зауважте також, що тимчасові таблиці потребують вручну VACUUM& ANALYZE. Я цитую посібник наCREATE TABLE :

Автовакуумінг демон не може отримати доступ і , отже , не може пилососити або аналізувати тимчасові таблиці. З цієї причини слід виконувати відповідні операції вакууму та аналізу за допомогою сеансних команд SQL. Наприклад, якщо тимчасова таблиця буде використовуватися в складних запитах, розумно запустити її ANALYZEна тимчасову таблицю після її заповнення.

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

Я не зовсім згоден з вибором дизайну постгресів, щоб зв'язати разом вакуум і проаналізувати, я бачив кілька випадків, коли бази даних, які роблять багато вставок / оновлень, але мало видаляють, ніколи не роблять аналіз і починають погано працювати.

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

Ви можете дістатись до налаштувань таблиці в gui на вкладці автоматичного вакууму, і ви побачите там параметри, які ви можете встановити незалежно від вакууму.

Налаштування закінчуються в таблиці повторів, і їх можна побачити із запитом

SELECT c.relname, c.reloptions FROM pg_class c where reloptions is not null

а вибіркова величина агресивного аналізу може бути такою

{autovacuum_enabled=true,autovacuum_analyze_threshold=10,autovacuum_analyze_scale_factor=.01}

Щоб побачити, коли останній раз ваші таблиці отримували запит на автоматичний аналіз

select 
    relname, 
    n_dead_tup, 
    n_tup_ins, 
    n_tup_upd, 
    n_tup_del, 
    last_autoanalyze, 
    autoanalyze_count 
from pg_stat_user_tables 
where last_autoanalyze is not null 
order by last_autoanalyze desc;