Preliminary patch for on-the-fly relpages/reltuples estimation

Lists: pgsql-patches
From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-patches(at)postgreSQL(dot)org
Subject: Preliminary patch for on-the-fly relpages/reltuples estimation
Date: 2004-11-30 00:14:01
Message-ID: 4155.1101773641@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-patches

I believe the attached patch incorporates all the ideas discussed in the
pghackers thread about using the current actual table size for planner
estimation purposes. The patch is not complete yet because (a) I
haven't touched the documentation, and (b) some of the regression tests
fail because of changes in plans; those expected-output files will need
adjustment.

Any comments, objections?

regards, tom lane

Attachment Content-Type Size
unknown_filename text/plain 19.0 KB

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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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>


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Markus Bertheau <twanger(at)bluetwanger(dot)de>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: Preliminary patch for on-the-fly relpages/reltuples estimation
Date: 2004-12-06 15:13:39
Message-ID: 1368.1102346019@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-patches

Markus Bertheau <twanger(at)bluetwanger(dot)de> writes:
>> + 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?

No. num_tuples is post-removal. The full expression is
(num_tuples + (num_tuples + tuples_removed)) / 2
which simplifies as above.

regards, tom lane