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

Commit6217a8c

Browse files
committed
Fix some bogosities in the code that deals with estimating the fraction
of tuples we are going to retrieve from a sub-SELECT. Must have beenhalf asleep when I did this code the first time :-(
1 parenta164208 commit6217a8c

File tree

3 files changed

+42
-29
lines changed

3 files changed

+42
-29
lines changed

‎src/backend/optimizer/path/costsize.c‎

Lines changed: 11 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -42,7 +42,7 @@
4242
* Portions Copyright (c) 1994, Regents of the University of California
4343
*
4444
* IDENTIFICATION
45-
* $Header: /cvsroot/pgsql/src/backend/optimizer/path/costsize.c,v 1.52 2000/02/15 20:49:16 tgl Exp $
45+
* $Header: /cvsroot/pgsql/src/backend/optimizer/path/costsize.c,v 1.53 2000/03/14 02:23:14 tgl Exp $
4646
*
4747
*-------------------------------------------------------------------------
4848
*/
@@ -687,8 +687,8 @@ cost_qual_eval_walker(Node *node, Cost *total)
687687
* (We assume that sub-selects that can be executed as
688688
* InitPlans have already been removed from the expression.)
689689
*
690-
* NOTE: this logic should agree withmake_subplan in
691-
* subselect.c.
690+
* NOTE: this logic should agree withthe estimates used by
691+
*make_subplan() in plan/subselect.c.
692692
*/
693693
{
694694
SubPlan*subplan= (SubPlan*)expr->oper;
@@ -701,16 +701,18 @@ cost_qual_eval_walker(Node *node, Cost *total)
701701
subcost=plan->startup_cost+
702702
(plan->total_cost-plan->startup_cost) /plan->plan_rows;
703703
}
704-
elseif (subplan->sublink->subLinkType==EXPR_SUBLINK)
705-
{
706-
/* assume we need all tuples */
707-
subcost=plan->total_cost;
708-
}
709-
else
704+
elseif (subplan->sublink->subLinkType==ALL_SUBLINK||
705+
subplan->sublink->subLinkType==ANY_SUBLINK)
710706
{
711707
/* assume we need 50% of the tuples */
712708
subcost=plan->startup_cost+
713709
0.50* (plan->total_cost-plan->startup_cost);
710+
/* XXX what if subplan has been materialized? */
711+
}
712+
else
713+
{
714+
/* assume we need all tuples */
715+
subcost=plan->total_cost;
714716
}
715717
*total+=subcost;
716718
}

‎src/backend/optimizer/plan/planner.c‎

Lines changed: 10 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@
88
*
99
*
1010
* IDENTIFICATION
11-
* $Header: /cvsroot/pgsql/src/backend/optimizer/plan/planner.c,v 1.76 2000/02/21 01:13:04 tgl Exp $
11+
* $Header: /cvsroot/pgsql/src/backend/optimizer/plan/planner.c,v 1.77 2000/03/14 02:23:15 tgl Exp $
1212
*
1313
*-------------------------------------------------------------------------
1414
*/
@@ -360,11 +360,14 @@ union_planner(Query *parse,
360360
* In GROUP BY mode, we have the little problem that we don't
361361
* really know how many input tuples will be needed to make a
362362
* group, so we can't translate an output LIMIT count into an
363-
* input count. For lack of a better idea, assume10% of the
363+
* input count. For lack of a better idea, assume25% of the
364364
* input data will be processed if there is any output limit.
365+
* However, if the caller gave us a fraction rather than an
366+
* absolute count, we can keep using that fraction (which amounts
367+
* to assuming that all the groups are about the same size).
365368
*/
366-
if (tuple_fraction>0.0)
367-
tuple_fraction=0.10;
369+
if (tuple_fraction >=1.0)
370+
tuple_fraction=0.25;
368371
/*
369372
* If both GROUP BY and ORDER BY are specified, we will need
370373
* two levels of sort --- and, therefore, certainly need to
@@ -386,11 +389,10 @@ union_planner(Query *parse,
386389
{
387390
/*
388391
* SELECT DISTINCT, like GROUP, will absorb an unpredictable
389-
* number of input tuples per output tuple. So, fall back to
390-
* our same old 10% default...
392+
* number of input tuples per output tuple. Handle the same way.
391393
*/
392-
if (tuple_fraction>0.0)
393-
tuple_fraction=0.10;
394+
if (tuple_fraction >=1.0)
395+
tuple_fraction=0.25;
394396
}
395397

396398
/* Generate the (sub) plan */

‎src/backend/optimizer/plan/subselect.c‎

Lines changed: 21 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -7,7 +7,7 @@
77
* Portions Copyright (c) 1994, Regents of the University of California
88
*
99
* IDENTIFICATION
10-
* $Header: /cvsroot/pgsql/src/backend/optimizer/plan/subselect.c,v 1.30 2000/03/1123:53:41 tgl Exp $
10+
* $Header: /cvsroot/pgsql/src/backend/optimizer/plan/subselect.c,v 1.31 2000/03/14 02:23:15 tgl Exp $
1111
*
1212
*-------------------------------------------------------------------------
1313
*/
@@ -134,25 +134,34 @@ make_subplan(SubLink *slink)
134134

135135
PlannerInitPlan=NULL;
136136

137-
PlannerQueryLevel++;/* webecomes child */
137+
PlannerQueryLevel++;/* webecome child */
138138

139139
/*
140140
* For an EXISTS subplan, tell lower-level planner to expect that
141-
* only the first tuple will be retrieved. For ALL, ANY,andMULTIEXPR
142-
*subplans,we will be able to stop evaluating if the test condition
143-
*fails,so very often not all the tuples will be retrieved; for lack
144-
*of abetter idea, specify 50% retrieval. ForEXPR_SUBLINK use default
145-
* behavior.
141+
* only the first tuple will be retrieved. For ALLandANY subplans,
142+
* we will be able to stop evaluating if the test condition fails,
143+
* so very often not all the tuples will be retrieved; for lack of a
144+
* better idea, specify 50% retrieval. ForEXPR and MULTIEXPR subplans,
145+
*use defaultbehavior (we're only expecting one row out, anyway).
146146
*
147-
* NOTE: if you change these numbers, also change cost_qual_eval_walker
148-
* in costsize.c.
147+
* NOTE: if you change these numbers, also change cost_qual_eval_walker()
148+
* in path/costsize.c.
149+
*
150+
* XXX If an ALL/ANY subplan is uncorrelated, we may decide to materialize
151+
* its result below. In that case it would've been better to specify
152+
* full retrieval. At present, however, we can only detect correlation
153+
* or lack of it after we've made the subplan :-(. Perhaps detection
154+
* of correlation should be done as a separate step. Meanwhile, we don't
155+
* want to be too optimistic about the percentage of tuples retrieved,
156+
* for fear of selecting a plan that's bad for the materialization case.
149157
*/
150158
if (slink->subLinkType==EXISTS_SUBLINK)
151159
tuple_fraction=1.0;/* just like a LIMIT 1 */
152-
elseif (slink->subLinkType==EXPR_SUBLINK)
153-
tuple_fraction=-1.0;/* default behavior */
154-
else
160+
elseif (slink->subLinkType==ALL_SUBLINK||
161+
slink->subLinkType==ANY_SUBLINK)
155162
tuple_fraction=0.5;/* 50% */
163+
else
164+
tuple_fraction=-1.0;/* default behavior */
156165

157166
node->plan=plan=union_planner(subquery,tuple_fraction);
158167

0 commit comments

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