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

Commit8dcaea7

Browse files
committed
Add a fudge factor to genericcostestimate() to prevent the planner from
thinking that indexes of different sizes are equally attractive. Pergripe from Jim Nasby. (I remain unconvinced that there's such a problemin existing releases, but CVS HEAD definitely has got a problem becauseof its new count-only-leaf-pages approach to indexscan costing.)
1 parenta794fb0 commit8dcaea7

File tree

1 file changed

+19
-1
lines changed

1 file changed

+19
-1
lines changed

‎src/backend/utils/adt/selfuncs.c‎

Lines changed: 19 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -15,7 +15,7 @@
1515
*
1616
*
1717
* IDENTIFICATION
18-
* $PostgreSQL: pgsql/src/backend/utils/adt/selfuncs.c,v 1.209 2006/07/14 14:52:24 momjian Exp $
18+
* $PostgreSQL: pgsql/src/backend/utils/adt/selfuncs.c,v 1.210 2006/07/24 01:19:48 tgl Exp $
1919
*
2020
*-------------------------------------------------------------------------
2121
*/
@@ -4657,6 +4657,24 @@ genericcostestimate(PlannerInfo *root,
46574657
*indexTotalCost=numIndexPages*random_page_cost;
46584658
}
46594659

4660+
/*
4661+
* A difficulty with the leaf-pages-only cost approach is that for
4662+
* small selectivities (eg, single index tuple fetched) all indexes
4663+
* will look equally attractive because we will estimate exactly 1
4664+
* leaf page to be fetched. All else being equal, we should prefer
4665+
* physically smaller indexes over larger ones. (An index might be
4666+
* smaller because it is partial or because it contains fewer columns;
4667+
* presumably the other columns in the larger index aren't useful to
4668+
* the query, or the larger index would have better selectivity.)
4669+
*
4670+
* We can deal with this by adding a very small "fudge factor" that
4671+
* depends on the index size. The fudge factor used here is one
4672+
* random_page_cost per 100000 index pages, which should be small
4673+
* enough to not alter index-vs-seqscan decisions, but will prevent
4674+
* indexes of different sizes from looking exactly equally attractive.
4675+
*/
4676+
*indexTotalCost+=index->pages*random_page_cost /100000.0;
4677+
46604678
/*
46614679
* CPU cost: any complex expressions in the indexquals will need to be
46624680
* evaluated once at the start of the scan to reduce them to runtime keys

0 commit comments

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