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