Re: Postgres 10 and auto vacuum

From: Michael Lewis <mlewis(at)entrata(dot)com>
To: Simon Windsor <simon(dot)windsor(at)cornfield(dot)me(dot)uk>
Cc: pgsql-general <pgsql-general(at)postgresql(dot)org>, Simon Windsor <simon(dot)windsor(at)paxport(dot)net>
Subject: Re: Postgres 10 and auto vacuum
Date: 2019-03-14 22:02:52
Message-ID: CAHOFxGonHXzGUn+Ge5ApnyvfvymcoApRyouZG31zsto++kG=dQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

>
> *autovacuum_analyze_threshold*
> *autovacuum_analyze_scale_factor*
>
Changing these will impact how often the table is analyzed based on the
rough count of changed rows. You may want to adjust autovacuum settings as
well so that dead space can be reused.

> *default_statistics_target*
>
Increasing this from default 100 will result in longer planning time, but
you may get a better plan (more consistently).

> What is the best option to ensure that the table statistics stay upto data
> and that the best Query Plan is generated.One option would be to use CRON
> and regenerate the table statistics every 15 minutes, or disable auto
> vacuum ANALYZE function, but neither of these options feel write.
>
You can check if autovacuum is working on this table by checking
pg_stat_user_tables or turning on logging of autovacuum and reviewing your
logs.

How does the auto vacuum analyze function work? Does it
>
>
> - use a subset of the whole table to regenerate the table statistics
>
> Yes. It scans 300*default_statistics_target rows and for each column
estimates null fraction, most common values and the frequency of those,
histogram_bounds and other info found in pg_stats.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Thomas Munro 2019-03-14 22:36:08 Re: ERROR: XX000: cannot update SecondarySnapshot during a parallel operation
Previous Message Simon Windsor 2019-03-14 21:38:42 Postgres 10 and auto vacuum