Re: pg_stat_get_last_vacuum_time(): why non-FULL?

Поиск
Список
Период
Сортировка
От Martín Marqués
Тема Re: pg_stat_get_last_vacuum_time(): why non-FULL?
Дата
Msg-id CABeG9Luqrn6fGVYDaEMk+8ar4aBjXSRzPeg_WUg14Z1Mh0V4Ug@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_stat_get_last_vacuum_time(): why non-FULL?  (CR Lender <crlender@gmail.com>)
Ответы Re: pg_stat_get_last_vacuum_time(): why non-FULL?
Список pgsql-general
2013/3/27 CR Lender <crlender@gmail.com>:
>
>> Also, a VACUUM FULL is an extreme form of
>> maintenance which should rarely be needed; if you find that you
>> need to run VACUUM FULL, something is probably being done wrong
>> which should be fixed so that you don't need to continue to do such
>> extreme maintenance.
>
> In this case I was only trying to make sense of an existing database
> (8.3). The statistics in pg_stats were way off for some tables, so I
> wanted to see if (auto)vacuum and (auto)analyze were being run.
> pg_stat_all_tables() showed last_autoanalyze at >400 days for some of
> the larger tables. There used to be a weekly cron job with VACUUM FULL
> ANALYZE, and I was trying to find out if that cron job was still active.
>

What's your autovacuum configuration? autovacuum_vacuum_threshold?
autovacuum_analyze_threshold? autovacuum_vacuum_scale_factor?
autovacuum_analyze_scale_factor?

Related to your 400+ days not vacuumed tables, are you sure those
tables have data changes (INSERT/UPDATE/DELETE)? I have some static
tables with over a year of no vacuum (and autovacuum field never ran
on that relation).

What does n_dead_tup show?

--
Martín Marqués
select 'martin.marques' || '@' || 'gmail.com'
DBA, Programador, Administrador


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

Предыдущее
От: salah jubeh
Дата:
Сообщение: Re: bloating index, pg_restore
Следующее
От: Gavan Schneider
Дата:
Сообщение: Re: Money casting too liberal?