{"shas":[["b4b6923e03f4d29636a94f6f4cc2f5cf6298b8c8","ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","Fix VACUUM so that it always updates pg_class.reltuples/relpages.\n\nWhen we added the ability for vacuum to skip heap pages by consulting the\nvisibility map, we made it just not update the reltuples/relpages\nstatistics if it skipped any pages.  But this could leave us with extremely\nout-of-date stats for a table that contains any unchanging areas,\nespecially for TOAST tables which never get processed by ANALYZE.  In\nparticular this could result in autovacuum making poor decisions about when\nto process the table, as in recent report from Florian Helmberger.  And in\ngeneral it's a bad idea to not update the stats at all.  Instead, use the\nprevious values of reltuples/relpages as an estimate of the tuple density\nin unvisited pages.  This approach results in a \"moving average\" estimate\nof reltuples, which should converge to the correct value over multiple\nVACUUM and ANALYZE cycles even when individual measurements aren't very\ngood.\n\nThis new method for updating reltuples is used by both VACUUM and ANALYZE,\nwith the result that we no longer need the grotty interconnections that\ncaused ANALYZE to not update the stats depending on what had happened\nin the parent VACUUM command.\n\nAlso, fix the logic for skipping all-visible pages during VACUUM so that it\nlooks ahead rather than behind to decide what to do, as per a suggestion\nfrom Greg Stark.  This eliminates useless scanning of all-visible pages at\nthe start of the relation or just after a not-all-visible page.  In\nparticular, the first few pages of the relation will not be invariably\nincluded in the scanned pages, which seems to help in not overweighting\nthem in the reltuples estimate.\n\nBack-patch to 8.4, where the visibility map was introduced.","Tom Lane"]],"ref":"refs/heads/master","size":1,"head":"b4b6923e03f4d29636a94f6f4cc2f5cf6298b8c8","push_id":32659499}