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

Commited275ae

Browse files
committed
The attached patch fixes some spelling mistakes, makes the
comments on one of the optimizer functions a lot moreclear, adds a summary of the recent KSQO discussion to thecomments in the code, adds regression tests for the bug withsequence state Tom fixed recently and another reg. test, andremoves some PostQuel legacy stuff: ExecAppend -> ExecInsert,ExecRetrieve -> ExecSelect, etc. This was changed because theelog() messages from this routine are user-visible, so weshould be using the SQL terms.Neil Conway
1 parent8a94628 commited275ae

File tree

13 files changed

+125
-98
lines changed

13 files changed

+125
-98
lines changed

‎src/backend/executor/execMain.c

Lines changed: 37 additions & 41 deletions
Original file line numberDiff line numberDiff line change
@@ -27,7 +27,7 @@
2727
*
2828
*
2929
* IDENTIFICATION
30-
* $Header: /cvsroot/pgsql/src/backend/executor/execMain.c,v 1.165 2002/06/20 20:29:27 momjian Exp $
30+
* $Header: /cvsroot/pgsql/src/backend/executor/execMain.c,v 1.166 2002/06/25 17:27:20 momjian Exp $
3131
*
3232
*-------------------------------------------------------------------------
3333
*/
@@ -62,14 +62,14 @@ static TupleTableSlot *ExecutePlan(EState *estate, Plan *plan,
6262
longnumberTuples,
6363
ScanDirectiondirection,
6464
DestReceiver*destfunc);
65-
staticvoidExecRetrieve(TupleTableSlot*slot,
65+
staticvoidExecSelect(TupleTableSlot*slot,
6666
DestReceiver*destfunc,
6767
EState*estate);
68-
staticvoidExecAppend(TupleTableSlot*slot,ItemPointertupleid,
68+
staticvoidExecInsert(TupleTableSlot*slot,ItemPointertupleid,
6969
EState*estate);
7070
staticvoidExecDelete(TupleTableSlot*slot,ItemPointertupleid,
7171
EState*estate);
72-
staticvoidExecReplace(TupleTableSlot*slot,ItemPointertupleid,
72+
staticvoidExecUpdate(TupleTableSlot*slot,ItemPointertupleid,
7373
EState*estate);
7474
staticTupleTableSlot*EvalPlanQualNext(EState*estate);
7575
staticvoidEndEvalPlanQual(EState*estate);
@@ -251,7 +251,7 @@ ExecCheckQueryPerms(CmdType operation, Query *parseTree, Plan *plan)
251251
ExecCheckRTPerms(parseTree->rtable,operation);
252252

253253
/*
254-
* Search for subplans andAPPEND nodes to check their rangetables.
254+
* Search for subplans andINSERT nodes to check their rangetables.
255255
*/
256256
ExecCheckPlanPerms(plan,parseTree->rtable,operation);
257257
}
@@ -583,7 +583,7 @@ InitPlan(CmdType operation, Query *parseTree, Plan *plan, EState *estate)
583583
/*
584584
* Get the tuple descriptor describing the type of tuples to return.
585585
* (this is especially important if we are creating a relation with
586-
* "retrieve into")
586+
* "SELECT INTO")
587587
*/
588588
tupType=ExecGetTupType(plan);/* tuple descriptor */
589589

@@ -892,7 +892,7 @@ EndPlan(Plan *plan, EState *estate)
892892
*Retrieves all tuples if numberTuples is 0
893893
*
894894
*result is either a slot containing the last tuple in the case
895-
*of aRETRIEVE or NULL otherwise.
895+
*of aSELECT or NULL otherwise.
896896
*
897897
* Note: the ctid attribute is a 'junk' attribute that is removed before the
898898
* user can see it
@@ -1068,29 +1068,26 @@ lnext:;
10681068

10691069
slot=ExecStoreTuple(newTuple,/* tuple to store */
10701070
junkfilter->jf_resultSlot,/* dest slot */
1071-
InvalidBuffer,/* this tuple has no
1072-
* buffer */
1071+
InvalidBuffer,/* this tuple has no buffer */
10731072
true);/* tuple should be pfreed */
1074-
}/* if (junkfilter... */
1073+
}
10751074

10761075
/*
10771076
* now that we have a tuple, do the appropriate thing with it..
10781077
* either return it to the user, add it to a relation someplace,
10791078
* delete it from a relation, or modify some of its attributes.
10801079
*/
1081-
10821080
switch (operation)
10831081
{
10841082
caseCMD_SELECT:
1085-
ExecRetrieve(slot,/* slot containing tuple */
1086-
destfunc,/* destination's tuple-receiver
1087-
* obj */
1088-
estate);/* */
1083+
ExecSelect(slot,/* slot containing tuple */
1084+
destfunc,/* destination's tuple-receiver obj */
1085+
estate);
10891086
result=slot;
10901087
break;
10911088

10921089
caseCMD_INSERT:
1093-
ExecAppend(slot,tupleid,estate);
1090+
ExecInsert(slot,tupleid,estate);
10941091
result=NULL;
10951092
break;
10961093

@@ -1100,7 +1097,7 @@ lnext:;
11001097
break;
11011098

11021099
caseCMD_UPDATE:
1103-
ExecReplace(slot,tupleid,estate);
1100+
ExecUpdate(slot,tupleid,estate);
11041101
result=NULL;
11051102
break;
11061103

@@ -1121,25 +1118,25 @@ lnext:;
11211118

11221119
/*
11231120
* here, result is either a slot containing a tuple in the case of a
1124-
*RETRIEVE or NULL otherwise.
1121+
*SELECT or NULL otherwise.
11251122
*/
11261123
returnresult;
11271124
}
11281125

11291126
/* ----------------------------------------------------------------
1130-
*ExecRetrieve
1127+
*ExecSelect
11311128
*
1132-
*RETRIEVEs are easy.. we just pass the tuple to the appropriate
1129+
*SELECTs are easy.. we just pass the tuple to the appropriate
11331130
*print function. The only complexity is when we do a
1134-
*"retrieve into", in which case we insert the tuple into
1131+
*"SELECT INTO", in which case we insert the tuple into
11351132
*the appropriate relation (note: this is a newly created relation
11361133
*so we don't need to worry about indices or locks.)
11371134
* ----------------------------------------------------------------
11381135
*/
11391136
staticvoid
1140-
ExecRetrieve(TupleTableSlot*slot,
1141-
DestReceiver*destfunc,
1142-
EState*estate)
1137+
ExecSelect(TupleTableSlot*slot,
1138+
DestReceiver*destfunc,
1139+
EState*estate)
11431140
{
11441141
HeapTupletuple;
11451142
TupleDescattrtype;
@@ -1169,16 +1166,15 @@ ExecRetrieve(TupleTableSlot *slot,
11691166
}
11701167

11711168
/* ----------------------------------------------------------------
1172-
*ExecAppend
1169+
*ExecInsert
11731170
*
1174-
*APPENDs are trickier.. we have to insert the tuple into
1171+
*INSERTs are trickier.. we have to insert the tuple into
11751172
*the base relation and insert appropriate tuples into the
11761173
*index relations.
11771174
* ----------------------------------------------------------------
11781175
*/
1179-
11801176
staticvoid
1181-
ExecAppend(TupleTableSlot*slot,
1177+
ExecInsert(TupleTableSlot*slot,
11821178
ItemPointertupleid,
11831179
EState*estate)
11841180
{
@@ -1227,7 +1223,7 @@ ExecAppend(TupleTableSlot *slot,
12271223
* Check the constraints of the tuple
12281224
*/
12291225
if (resultRelationDesc->rd_att->constr)
1230-
ExecConstraints("ExecAppend",resultRelInfo,slot,estate);
1226+
ExecConstraints("ExecInsert",resultRelInfo,slot,estate);
12311227

12321228
/*
12331229
* insert the tuple
@@ -1259,7 +1255,7 @@ ExecAppend(TupleTableSlot *slot,
12591255
/* ----------------------------------------------------------------
12601256
*ExecDelete
12611257
*
1262-
*DELETE is likeappend, we delete the tuple and its
1258+
*DELETE is likeUPDATE, we delete the tuple and its
12631259
*index tuples.
12641260
* ----------------------------------------------------------------
12651261
*/
@@ -1346,18 +1342,18 @@ ldelete:;
13461342
}
13471343

13481344
/* ----------------------------------------------------------------
1349-
*ExecReplace
1345+
*ExecUpdate
13501346
*
1351-
*note: we can't runreplace queries with transactions
1352-
*off becausereplaces are actuallyappends and our
1353-
*scan will mistakenly loop forever,replacing the tuple
1354-
*it justappended..This should be fixed but until it
1347+
*note: we can't runUPDATE queries with transactions
1348+
*off becauseUPDATEs are actuallyINSERTs and our
1349+
*scan will mistakenly loop forever,updating the tuple
1350+
*it justinserted..This should be fixed but until it
13551351
*is, we don't want to get stuck in an infinite loop
13561352
*which corrupts your database..
13571353
* ----------------------------------------------------------------
13581354
*/
13591355
staticvoid
1360-
ExecReplace(TupleTableSlot*slot,
1356+
ExecUpdate(TupleTableSlot*slot,
13611357
ItemPointertupleid,
13621358
EState*estate)
13631359
{
@@ -1373,7 +1369,7 @@ ExecReplace(TupleTableSlot *slot,
13731369
*/
13741370
if (IsBootstrapProcessingMode())
13751371
{
1376-
elog(WARNING,"ExecReplace: replace can't run without transactions");
1372+
elog(WARNING,"ExecUpdate: UPDATE can't run without transactions");
13771373
return;
13781374
}
13791375

@@ -1424,7 +1420,7 @@ ExecReplace(TupleTableSlot *slot,
14241420
*/
14251421
lreplace:;
14261422
if (resultRelationDesc->rd_att->constr)
1427-
ExecConstraints("ExecReplace",resultRelInfo,slot,estate);
1423+
ExecConstraints("ExecUpdate",resultRelInfo,slot,estate);
14281424

14291425
/*
14301426
* replace the heap tuple
@@ -1472,7 +1468,7 @@ lreplace:;
14721468
/*
14731469
* Note: instead of having to update the old index tuples associated
14741470
* with the heap tuple, all we do is form and insert new index tuples.
1475-
* This is becausereplaces are actuallydeletes andinserts and index
1471+
* This is becauseUPDATEs are actuallyDELETEs andINSERTs and index
14761472
* tuple deletion is done automagically by the vacuum daemon. All we
14771473
* do is insert new index tuples. -cim 9/27/89
14781474
*/
@@ -1481,7 +1477,7 @@ lreplace:;
14811477
* process indices
14821478
*
14831479
* heap_update updates a tuple in the base relation by invalidating it
1484-
* and thenappending a new tuple to the relation.As a side effect,
1480+
* and theninserting a new tuple to the relation.As a side effect,
14851481
* the tupleid of the new tuple is placed in the new tuple's t_ctid
14861482
* field. So we now insert index tuples using the new tupleid stored
14871483
* there.
@@ -1554,7 +1550,7 @@ ExecRelCheck(ResultRelInfo *resultRelInfo,
15541550
}
15551551

15561552
void
1557-
ExecConstraints(char*caller,ResultRelInfo*resultRelInfo,
1553+
ExecConstraints(constchar*caller,ResultRelInfo*resultRelInfo,
15581554
TupleTableSlot*slot,EState*estate)
15591555
{
15601556
Relationrel=resultRelInfo->ri_RelationDesc;

‎src/backend/executor/execUtils.c

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@
88
*
99
*
1010
* IDENTIFICATION
11-
* $Header: /cvsroot/pgsql/src/backend/executor/execUtils.c,v 1.83 2002/06/20 20:29:28 momjian Exp $
11+
* $Header: /cvsroot/pgsql/src/backend/executor/execUtils.c,v 1.84 2002/06/25 17:27:20 momjian Exp $
1212
*
1313
*-------------------------------------------------------------------------
1414
*/
@@ -18,7 +18,7 @@
1818
*
1919
*ExecOpenIndices\
2020
*ExecCloseIndices | referenced by InitPlan, EndPlan,
21-
*ExecInsertIndexTuples/ExecAppend, ExecReplace
21+
*ExecInsertIndexTuples/ExecInsert, ExecUpdate
2222
*
2323
*RegisterExprContextCallback Register function shutdown callback
2424
*UnregisterExprContextCallback Deregister function shutdown callback

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

Lines changed: 6 additions & 6 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.85 2002/06/20 20:29:29 momjian Exp $
45+
* $Header: /cvsroot/pgsql/src/backend/optimizer/path/costsize.c,v 1.86 2002/06/25 17:27:20 momjian Exp $
4646
*
4747
*-------------------------------------------------------------------------
4848
*/
@@ -154,11 +154,11 @@ cost_seqscan(Path *path, Query *root,
154154
*
155155
* Given a guesstimated cache size, we estimate the actual I/O cost per page
156156
* with the entirely ad-hoc equations:
157-
*for rel_size <= effective_cache_size:
158-
*1 + (random_page_cost/2-1) * (rel_size/effective_cache_size) ** 2
159-
*for rel_size >= effective_cache_size:
160-
*random_page_cost * (1 - (effective_cache_size/rel_size)/2)
161-
* These give the right asymptotic behavior (=> 1.0 asrel_size becomes
157+
*if relpages >= effective_cache_size:
158+
*random_page_cost * (1 - (effective_cache_size/relpages)/2)
159+
*if relpages < effective_cache_size:
160+
*1 + (random_page_cost/2-1) * (relpages/effective_cache_size) ** 2
161+
* These give the right asymptotic behavior (=> 1.0 asrelpages becomes
162162
* small, => random_page_cost as it becomes large) and meet in the middle
163163
* with the estimate that the cache is about 50% effective for a relation
164164
* of the same size as effective_cache_size. (XXX this is probably all

‎src/backend/optimizer/prep/_deadcode/prepkeyset.c

Lines changed: 9 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11
/*-------------------------------------------------------------------------
22
*
33
* prepkeyset.c
4-
* Specialpreperation for keyset queries.
4+
* Specialpreparation for keyset queries (KSQO).
55
*
66
* Portions Copyright (c) 1996-2002, PostgreSQL Global Development Group
77
* Portions Copyright (c) 1994, Regents of the University of California
@@ -14,12 +14,6 @@
1414
#include"postgres.h"
1515
#include"optimizer/planmain.h"
1616

17-
/*
18-
* Node_Copy
19-
* a macro to simplify calling of copyObject on the specified field
20-
*/
21-
#defineNode_Copy(from,newnode,field) newnode->field = copyObject(from->field)
22-
2317
bool_use_keyset_query_optimizer= FALSE;
2418

2519
#ifdefENABLE_KEY_SET_QUERY
@@ -55,13 +49,20 @@ static intTotalExpr;
5549
* a HAVING, or a GROUP BY.It must be a single table and have KSQO
5650
* set to 'on'.
5751
*
58-
* The primary use of this transformation is to avoid theexponrntial
52+
* The primary use of this transformation is to avoid theexponential
5953
* memory consumption of cnfify() and to make use of index access
6054
* methods.
6155
*
6256
* daveh@insightdist.com 1998-08-31
6357
*
6458
* May want to also prune out duplicate terms.
59+
*
60+
* XXX: this code is currently not compiled because it has not been
61+
* updated to work with the re-implementation of UNION/INTERSECT/EXCEPT
62+
* in PostgreSQL 7.1. However, it is of questionable value in any
63+
* case, because it changes the semantics of the original query:
64+
* UNION will add an implicit SELECT DISTINCT, which might change
65+
* the results that are returned.
6566
**********************************************************************/
6667
void
6768
transformKeySetQuery(Query*origNode)

‎src/include/executor/executor.h

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -7,7 +7,7 @@
77
* Portions Copyright (c) 1996-2002, PostgreSQL Global Development Group
88
* Portions Copyright (c) 1994, Regents of the University of California
99
*
10-
* $Id: executor.h,v 1.66 2002/06/20 20:29:49 momjian Exp $
10+
* $Id: executor.h,v 1.67 2002/06/25 17:27:20 momjian Exp $
1111
*
1212
*-------------------------------------------------------------------------
1313
*/
@@ -52,7 +52,7 @@ extern TupleDesc ExecutorStart(QueryDesc *queryDesc, EState *estate);
5252
externTupleTableSlot*ExecutorRun(QueryDesc*queryDesc,EState*estate,
5353
ScanDirectiondirection,longcount);
5454
externvoidExecutorEnd(QueryDesc*queryDesc,EState*estate);
55-
externvoidExecConstraints(char*caller,ResultRelInfo*resultRelInfo,
55+
externvoidExecConstraints(constchar*caller,ResultRelInfo*resultRelInfo,
5656
TupleTableSlot*slot,EState*estate);
5757
externTupleTableSlot*EvalPlanQual(EState*estate,Indexrti,
5858
ItemPointertid);

0 commit comments

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