Re: Why is my table not autovacuuming?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Same concerns as Phil's reply. Are the numbers in pg_stat_all_tables not part of what autovacuum looks at? I assume those numbers would be updated by autoanalyze but if that only kicks in at 10% scale factor then that wouldn't happen for a while either? Seems like there's a huge disconnect here, or I just don't have my head around this properly. Or both.

Don.

On Mon, Aug 28, 2017 at 10:59 AM, Joe Conway <mail@xxxxxxxxxxxxx> wrote:
On 08/28/2017 08:43 AM, Don Seiler wrote:
> PostgreSQL 9.2.18. I have a table with 71M rows (via select count). In
> pg_stat_activity, n_live_tups is 170K, n_dead_tups is slightly more than
> that (203K). The autovacuum parameter is on, the scale factor is 0.2
> (default) and threshold is 50 (default), autovacuum_max_workers is 3.
> There are no custom autovacuum thresholds set for this table. The
> last_autovacuum field is null.

<snip>

> Wondering why my autovacuum daemon appears to be acting lazily?

Autovac will kick in at (threshold + (scale_factor x 71M)), i.e. about
14.2 million dead rows. You are currently nowhere close to that.

That said, the default scale_factor is not good to such a large table.
Reduce it significantly. I often will find it necessary to use custom
values for large tables. One strategy I have used is scale_factor = 0
and threshold = <num_dead_rows_max_desired>.

Joe

--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development




--
Don Seiler
www.seiler.us

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux