From 73ed6d61bd662324dee94f40539aaf0181fe16ce Mon Sep 17 00:00:00 2001
From: Tom Lane <tgl@sss.pgh.pa.us>
Date: Fri, 25 Mar 2005 22:51:31 +0000
Subject: [PATCH] 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 ...
---
src/backend/commands/vacuumlazy.c | 73 ++++++-------------------------
1 file 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",
@@ -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
*
--
GitLab