mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Remove lazy_update_relstats; go back to having VACUUM just record the

Browse Source 
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 ...
This commit is contained in:
Tom Lane 2005-03-25 22:51:31 +00:00
parent adb1a6e95b
commit 73ed6d61bd
1 changed files with 13 additions and 60 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

73
src/backend/commands/vacuumlazy.c
View File

@ -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
*