Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit0c0151a

Browse files
committed
Initialize reltuples = 1000, relpages = 10 in a newly created
relation, rather than zeroes. This prevents the optimizer from makingfoolish choices (ie, using nested-loop plans) on never-yet-vacuumed tables.This is a hack, of course. Keeping accurate track of these statisticswould be a cleaner solution, but it's far from clear that it'd be worththe cost of doing so. In any case we're not going to do that for 6.5.In the meantime, this quick hack provides a useful performance improvementin the regression tests and in many real-world scenarios.
1 parentdbce02f commit0c0151a

File tree

1 file changed

+24
-2
lines changed

1 file changed

+24
-2
lines changed

‎src/backend/catalog/heap.c

Lines changed: 24 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -7,7 +7,7 @@
77
*
88
*
99
* IDENTIFICATION
10-
* $Header: /cvsroot/pgsql/src/backend/catalog/heap.c,v 1.76 1999/03/17 22:52:48 momjian Exp $
10+
* $Header: /cvsroot/pgsql/src/backend/catalog/heap.c,v 1.77 1999/04/15 04:08:07 tgl Exp $
1111
*
1212
*
1313
* INTERFACE ROUTINES
@@ -661,7 +661,29 @@ AddNewRelationTuple(Relation pg_class_desc,
661661
new_rel_reltup=new_rel_desc->rd_rel;
662662

663663
/* CHECK should get new_rel_oid first via an insert then use XXX */
664-
/* new_rel_reltup->reltuples = 1; *//* XXX */
664+
665+
/* ----------------
666+
* Here we insert bogus estimates of the size of the new relation.
667+
* In reality, of course, the new relation has 0 tuples and pages,
668+
* and if we were tracking these statistics accurately then we'd
669+
* set the fields that way. But at present the stats will be updated
670+
* only by VACUUM or CREATE INDEX, and the user might insert a lot of
671+
* tuples before he gets around to doing either of those. So, instead
672+
* of saying the relation is empty, we insert guesstimates. The point
673+
* is to keep the optimizer from making really stupid choices on
674+
* never-yet-vacuumed tables; so the estimates need only be large
675+
* enough to discourage the optimizer from using nested-loop plans.
676+
* With this hack, nested-loop plans will be preferred only after
677+
* the table has been proven to be small by VACUUM or CREATE INDEX.
678+
* (NOTE: if user does CREATE TABLE, then CREATE INDEX, then loads
679+
* the table, he still loses until he vacuums, because CREATE INDEX
680+
* will set reltuples to zero. Can't win 'em all. Maintaining the
681+
* stats on-the-fly would solve the problem, but the overhead of that
682+
* would likely cost more than it'd save.)
683+
* ----------------
684+
*/
685+
new_rel_reltup->relpages=10;/* bogus estimates */
686+
new_rel_reltup->reltuples=1000;
665687

666688
new_rel_reltup->relowner=GetUserId();
667689
new_rel_reltup->relkind=relkind;

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp