Remove lazy_update_relstats; go back to having VACUUM just record the

actual number of unremoved tuples as pg_class.reltuples.  The idea of
trying to estimate a steady state condition still seems attractive, but
this particular implementation crashed and burned ...

diff --git a/src/backend/commands/vacuumlazy.c b/src/backend/commands/vacuumlazy.c
index bc12f1150708d6433eb10df314553c0303104add..d6861be7157b6afdc0f3613a546f77192bbe3c81 100644 (file)
--- a/src/backend/commands/vacuumlazy.c
+++ b/src/backend/commands/vacuumlazy.c
@@ -31,7 +31,7 @@
  *
  *
  * IDENTIFICATION
- *   $PostgreSQL: pgsql/src/backend/commands/vacuumlazy.c,v 1.51 2005/03/20 22:00:52 tgl Exp $
+ *   $PostgreSQL: pgsql/src/backend/commands/vacuumlazy.c,v 1.52 2005/03/25 22:51:31 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -107,10 +107,6 @@ static int lazy_vacuum_page(Relation onerel, BlockNumber blkno, Buffer buffer,
 static void lazy_truncate_heap(Relation onerel, LVRelStats *vacrelstats);
 static BlockNumber count_nondeletable_pages(Relation onerel,
                         LVRelStats *vacrelstats);
-static void lazy_update_relstats(Relation rel, BlockNumber num_pages,
-                                BlockNumber pages_removed,
-                                double num_tuples, double tuples_removed,
-                                bool hasindex);
 static void lazy_space_alloc(LVRelStats *vacrelstats, BlockNumber relblocks);
 static void lazy_record_dead_tuple(LVRelStats *vacrelstats,
                       ItemPointer itemptr);
@@ -180,10 +176,10 @@ lazy_vacuum_rel(Relation onerel, VacuumStmt *vacstmt)
    lazy_update_fsm(onerel, vacrelstats);
 
    /* Update statistics in pg_class */
-   lazy_update_relstats(onerel, vacrelstats->rel_pages,
-                        vacrelstats->pages_removed,
-                        vacrelstats->rel_tuples, vacrelstats->tuples_deleted,
-                        hasindex);
+   vac_update_relstats(RelationGetRelid(onerel),
+                       vacrelstats->rel_pages,
+                       vacrelstats->rel_tuples,
+                       hasindex);
 }
 
 
@@ -622,9 +618,10 @@ lazy_scan_index(Relation indrel, LVRelStats *vacrelstats)
        return;
 
    /* now update statistics in pg_class */
-   lazy_update_relstats(indrel, stats->num_pages, stats->pages_removed,
-                        stats->num_index_tuples, stats->tuples_removed,
-                        false);
+   vac_update_relstats(RelationGetRelid(indrel),
+                       stats->num_pages,
+                       stats->num_index_tuples,
+                       false);
 
    ereport(elevel,
       (errmsg("index \"%s\" now contains %.0f row versions in %u pages",
@@ -697,9 +694,10 @@ lazy_vacuum_index(Relation indrel,
    *index_pages_removed += stats->pages_removed;
 
    /* now update statistics in pg_class */
-   lazy_update_relstats(indrel, stats->num_pages, *index_pages_removed,
-                        stats->num_index_tuples, *index_tups_vacuumed,
-                        false);
+   vac_update_relstats(RelationGetRelid(indrel),
+                       stats->num_pages,
+                       stats->num_index_tuples,
+                       false);
 
    ereport(elevel,
       (errmsg("index \"%s\" now contains %.0f row versions in %u pages",
@@ -922,51 +920,6 @@ count_nondeletable_pages(Relation onerel, LVRelStats *vacrelstats)
    return vacrelstats->nonempty_pages;
 }
 
-/*
- * lazy_update_relstats - update pg_class statistics for a table or index
- *
- * We always want to set relpages to an accurate value.  However, for lazy
- * VACUUM it seems best to set reltuples to the average of the number of
- * rows before vacuuming and the number after vacuuming, rather than just
- * using the number after vacuuming.  This will result in the best average
- * performance in a steady-state situation where VACUUMs are performed
- * regularly on a table of roughly constant size, assuming that the physical
- * number of pages in the table stays about the same throughout.  (Note that
- * we do not apply the same logic to VACUUM FULL, because it repacks the table
- * and thereby boosts the tuple density.)
- *
- * An important point is that when the table size has decreased a lot during
- * vacuuming, the old reltuples count might give an overestimate of the tuple
- * density.  We handle this by scaling down the old reltuples count by the
- * fraction by which the table has shortened before we merge it with the
- * new reltuples count.  In particular this means that when relpages goes to
- * zero, reltuples will immediately go to zero as well, causing the planner
- * to fall back on other estimation procedures as the table grows again.
- *
- * Because we do this math independently for the table and the indexes, it's
- * quite possible to end up with an index's reltuples different from the
- * table's, which is silly except in the case of partial indexes.  We don't
- * worry too much about that here; the planner contains filtering logic to
- * ensure it only uses sane estimates.
- */
-static void
-lazy_update_relstats(Relation rel, BlockNumber num_pages,
-                    BlockNumber pages_removed,
-                    double num_tuples, double tuples_removed,
-                    bool hasindex)
-{
-   double  old_num_tuples;
-
-   old_num_tuples = num_tuples + tuples_removed;
-   if (pages_removed > 0)
-       old_num_tuples *= (double) num_pages / (double) (num_pages + pages_removed);
-   if (old_num_tuples > num_tuples)
-       num_tuples = ceil((num_tuples + old_num_tuples) * 0.5);
-
-   vac_update_relstats(RelationGetRelid(rel), num_pages, num_tuples,
-                       hasindex);
-}
-
 /*
  * lazy_space_alloc - space allocation decisions for lazy vacuum
  *