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 ...

1 files changed, 13 insertions, 60 deletions

diff --git a/src/backend/commands/vacuumlazy.c b/src/backend/commands/vacuumlazy.c
index bc12f115070..d6861be7157 100644
--- 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",
@@ -923,51 +921,6 @@ count_nondeletable_pages(Relation onerel, LVRelStats *vacrelstats)
 }
 
 /*
- * 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
  *
  * See the comments at the head of this file for rationale.