On 11 August 2017 at 23:54, Erwin Brandstetter <brsaw...@gmail.com> wrote:
> On the one hand the manual for autovacuum_analyze_threshold claims here: > > https://www.postgresql.org/docs/current/static/runtime- > config-autovacuum.html#GUC-AUTOVACUUM-ANALYZE-THRESHOLD > > > Specifies the minimum number of inserted, updated or deleted tuples > needed to trigger an ANALYZE in any one table. > > Similar in pg_settings.short_desc: > > > Minimum number of tuple inserts, updates, or deletes prior to analyze. > > "Minimum" indicates "row_count >= vacuum threshold". (Well "prior" makes > that less clear ..) > > On the other hand the manual explains here: > > https://www.postgresql.org/docs/current/static/routine- > vacuuming.html#AUTOVACUUM > > > Otherwise, if the number of tuples obsoleted since the last VACUUM > exceeds the "vacuum threshold", the table is vacuumed. > > "Exceeds" indicates "row_count > vacuum threshold". > > Actual test results seem to support "row_count > vacuum threshold". See > test case here: > > https://dba.stackexchange.com/questions/181960/tiny-table- > causes-extreme-performance-degradation-fixed-by-forced- > vacuum-why/183283#183283 > > I suggest to either clarify the manual or change the code to actually use > >= instead of > ... and update the explanation for autovacuum accordingly. > > Same for autovacuum_vacuum_threshold. > Still incorrect in the manual. The specified number of obsoleted rows does *not* yet trigger an ANALYZE. Only the next one does. Off-by-one error. A simple fix could be to replace: *minimum number of inserted, updated or deleted tuples * with: * number of inserted, updated or deleted tuples that must be exceeded* Regards Erwin
