Re: [GENERAL] Autoanalyze oddity

Поиск
Список
Период
Сортировка
От Adrian Klaver
Тема Re: [GENERAL] Autoanalyze oddity
Дата
Msg-id e796c16a-56a6-698a-9d00-fd6974147dd9@aklaver.com
обсуждение исходный текст
Ответ на [GENERAL] Autoanalyze oddity  ("Peter J. Holzer" <hjp-pgsql@hjp.at>)
Ответы Re: [GENERAL] Autoanalyze oddity  ("Peter J. Holzer" <hjp-pgsql@hjp.at>)
Список pgsql-general
On 03/03/2017 12:33 AM, Peter J. Holzer wrote:
> This is with PostgreSQL 9.5.6 on Debian Linux.
>
> I noticed that according to pg_stat_user_tables autoanalyze has never
> run on a lot of tables. Here is one example:
>
> wdsah=> select * from pg_stat_user_tables where schemaname='public' and relname='facttable_wds_indexstats';
> ─[ RECORD 1 ]───────┬─────────────────────────
> relid               │ 112723
> schemaname          │ public
> relname             │ facttable_wds_indexstats
> seq_scan            │ 569
> seq_tup_read        │ 474779212
> idx_scan            │ 59184
> idx_tup_fetch       │ 59184
> n_tup_ins           │ 47128
> n_tup_upd           │ 0
> n_tup_del           │ 0
> n_tup_hot_upd       │ 0
> n_live_tup          │ 47128
> n_dead_tup          │ 0
> n_mod_since_analyze │ 47128
> last_vacuum         │ (∅)
> last_autovacuum     │ (∅)
> last_analyze        │ (∅)
> last_autoanalyze    │ (∅)
> vacuum_count        │ 0
> autovacuum_count    │ 0
> analyze_count       │ 0
> autoanalyze_count   │ 0
>
> wdsah=> select count(*) from facttable_wds_indexstats;
>  count
> ────────
>  857992
> (1 row)
>
> So, n_live_tup is way off, and n_tup_ins and n_mod_since_analyze also
> seem to be wrong. Looks like this hasn't been updated in a year or so.
> But track_counts is on:
>
> wdsah=> show track_counts;
>  track_counts
> ──────────────
>  on
> (1 row)

What are your settings for autovacuum?:

https://www.postgresql.org/docs/9.5/static/runtime-config-autovacuum.html

Have the storage parameters for the table been altered?:

https://www.postgresql.org/docs/9.5/static/sql-createtable.html#SQL-CREATETABLE-STORAGE-PARAMETERS

>
> And even if it wasn't, shouldn't the autovacuum daemon notice that
> n_mod_since_analyze is greater than n_live_tup *
> autovacuum_analyze_scale_factor and run an autoanalyze?

That value is added to autovacuum_analyze_threshold:

autovacuum_analyze_scale_factor (floating point)

     Specifies a fraction of the table size to add to
autovacuum_analyze_threshold when deciding whether to trigger an
ANALYZE. The default is 0.1 (10% of table size). This parameter can only
be set in the postgresql.conf file or on the server command line; but
the setting can be overridden for individual tables by changing table
storage parameters.

>
> But the really weird thing is that pg_stats seems to be reasonably
> current: I see entries in most_common_vals which were only inserted in
> January. Is it possible that autoanalyze runs without updating
> pg_stat_user_tables?
>
>         hp
>
>


--
Adrian Klaver
adrian.klaver@aklaver.com


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

Предыдущее
От: Artur Zakirov
Дата:
Сообщение: Re: [GENERAL] Full Text Search combined with Fuzzy
Следующее
От: Adrian Klaver
Дата:
Сообщение: Re: [GENERAL] Querying JSON Lists