Skip site navigation (1) Skip section navigation (2)

Re: Preliminary patch for on-the-fly relpages/reltuples

From: Markus Bertheau <twanger(at)bluetwanger(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: Preliminary patch for on-the-fly relpages/reltuples
Date: 2004-12-06 10:14:41
Message-ID: 1102328081.3382.1.camel@fc3 (view raw or flat)
Thread:
Lists: pgsql-patches
В Пнд, 29/11/2004 в 19:14 -0500, Tom Lane пишет:
> + /*
> +  * 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.)
> +  */
> + static void
> + lazy_update_relstats(Relation rel, BlockNumber num_pages,
> + 					 double num_tuples, double tuples_removed,
> + 					 bool hasindex)
> + {
> + 	num_tuples = ceil(num_tuples + tuples_removed * 0.5);

Not understanding a thing about the PG source code, and judging from the
variable names, wouldn't you want ceil(num_tuples + (num_tuples -
tuples_removed) * 0.5) instead?

> + 	vac_update_relstats(RelationGetRelid(rel), num_pages, num_tuples,
> + 						hasindex);
>   }

-- 
Markus Bertheau <twanger(at)bluetwanger(dot)de>


In response to

Responses

pgsql-patches by date

Next:From: laurie.burrowDate: 2004-12-06 13:25:09
Subject: Reverse engineering problem on views
Previous:From: Marko KreenDate: 2004-12-05 23:54:14
Subject: Re: patch contrib/pgcrypto for win32 (2)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group