RE: BUG #15067: Documentation or behaviour bug with autovacuumthresholds?

> > I think there is a documentation bug in the Autovacuum section:
> No, there isn't.
> "exceed" means "greater than". Hence, documentation is accurate.
> > I think there is a documentation bug in the Autovacuum section:
> No, there isn't.
> "exceed" means "greater than". Hence, documentation is accurate.

Hi Euler,

I had considered that, but if you do *exactly* the same number of updates as the threshold... wait... and then do a
singleupdate, it vacuums a single row, not threshold+1.  In my example:
 

1) autovacuum_vacuum_scale_factor = 0
2) autovacuum_vacuum_threshold = 500
3) Update 500 rows of a 1,000 row table
4) Wait 30 seconds
5) Update 1 row
6) NOTE:  "tuples: 1 removed" in the postgres.log, not "tuples: 501 removed".

< 2018-02-14 15:20:08.512 GMT > LOG:  automatic vacuum of table "postgres.public.autovacuum_threshold_test": index
scans:0
 
    pages: 0 removed, 7 remain, 0 skipped due to pins, 0 skipped frozen
    tuples: 1 removed, 1000 remain, 0 are dead but not yet removable


There are two potential issues with that:

1) The autovacuum_vacuum_threshold is 500, so it should never vacuum anything less... especially not a single tuple.
   (Is that a bug in autovacuum, triggering on less than the threshold?)

2) Nowhere does it ever mention "tuples: 500 removed", so what happened to the originally updated 500 tuples?
   - Did they get vacuumed silently?
     (Is that a bug in autovacuum, where it doesn't report correctly?)
   - Did they skip being vacuumed?
     (Are these rows being lost forever, adding to bloat?)


In short, what happened to the initial autovacuum_vacuum_threshold (500) updates, and why did autovacuum run on a
singlerow?
 

Cheers,
Greg.