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

Commit472d393

Browse files
committed
Rethink representation of index clauses' mapping to index columns.
In commite2c2c2e I made use of nestedlist structures to show which clauses went with which index columns, buton reflection that's a data structure that only an old-line Lisp hackercould love. Worse, it adds unnecessary complication to the many placesthat don't much care which clauses go with which index columns. Revertto the previous arrangement of flat lists of clauses, and instead add aparallel integer list of column numbers. The places that care about thepairing can chase both lists with forboth(), while the places that don'tcare just examine one list the same as before.The only real downside to this is that there are now two more lists thatneed to be passed to amcostestimate functions in case they care aboutcolumn matching (which btcostestimate does, so not passing the info is notan option). Rather than deal with 11-argument amcostestimate functions,pass just the IndexPath and expect the functions to extract fields from it.That gets us down to 7 arguments which is better than 11, and it seemsmore future-proof against likely additions to the information we keepabout an index path.
1 parente2c2c2e commit472d393

File tree

16 files changed

+543
-686
lines changed

16 files changed

+543
-686
lines changed

‎doc/src/sgml/indexam.sgml

Lines changed: 14 additions & 37 deletions
Original file line numberDiff line numberDiff line change
@@ -288,9 +288,7 @@ amcanreturn (Relation indexRelation);
288288
<programlisting>
289289
void
290290
amcostestimate (PlannerInfo *root,
291-
IndexOptInfo *index,
292-
List *indexQuals,
293-
List *indexOrderBys,
291+
IndexPath *path,
294292
RelOptInfo *outer_rel,
295293
Cost *indexStartupCost,
296294
Cost *indexTotalCost,
@@ -929,17 +927,15 @@ amrestrpos (IndexScanDesc scan);
929927
<programlisting>
930928
void
931929
amcostestimate (PlannerInfo *root,
932-
IndexOptInfo *index,
933-
List *indexQuals,
934-
List *indexOrderBys,
930+
IndexPath *path,
935931
RelOptInfo *outer_rel,
936932
Cost *indexStartupCost,
937933
Cost *indexTotalCost,
938934
Selectivity *indexSelectivity,
939935
double *indexCorrelation);
940936
</programlisting>
941937

942-
The firstfive parameters are inputs:
938+
The firstthree parameters are inputs:
943939

944940
<variablelist>
945941
<varlistentry>
@@ -952,32 +948,11 @@ amcostestimate (PlannerInfo *root,
952948
</varlistentry>
953949

954950
<varlistentry>
955-
<term><parameter>index</></term>
951+
<term><parameter>path</></term>
956952
<listitem>
957953
<para>
958-
The index being considered.
959-
</para>
960-
</listitem>
961-
</varlistentry>
962-
963-
<varlistentry>
964-
<term><parameter>indexQuals</></term>
965-
<listitem>
966-
<para>
967-
List of index qual clauses (implicitly ANDed);
968-
a <symbol>NIL</> list indicates no qualifiers are available.
969-
Note that the list contains expression trees with RestrictInfo nodes
970-
at the top, not ScanKeys.
971-
</para>
972-
</listitem>
973-
</varlistentry>
974-
975-
<varlistentry>
976-
<term><parameter>indexOrderBys</></term>
977-
<listitem>
978-
<para>
979-
List of indexable ORDER BY operators, or <symbol>NIL</> if none.
980-
Note that the list contains expression trees, not ScanKeys.
954+
The index access path being considered. All fields except cost and
955+
selectivity values are valid.
981956
</para>
982957
</listitem>
983958
</varlistentry>
@@ -988,7 +963,8 @@ amcostestimate (PlannerInfo *root,
988963
<para>
989964
If the index is being considered for use in a join inner indexscan,
990965
the planner's information about the outer side of the join. Otherwise
991-
<symbol>NULL</>. When non-<symbol>NULL</>, some of the qual clauses will be join clauses
966+
<symbol>NULL</>. When non-<symbol>NULL</>, some of the qual clauses
967+
will be join clauses for joins
992968
with this rel rather than being simple restriction clauses. Also,
993969
the cost estimator should expect that the index scan will be repeated
994970
for each row of the outer rel.
@@ -1055,7 +1031,7 @@ amcostestimate (PlannerInfo *root,
10551031
row should usually be taken as <varname>cpu_index_tuple_cost</>. In
10561032
addition, an appropriate multiple of <varname>cpu_operator_cost</> should
10571033
be charged for any comparison operators invoked during index processing
1058-
(especially evaluation of the<literal>indexQuals</> themselves).
1034+
(especially evaluation of theindexquals themselves).
10591035
</para>
10601036

10611037
<para>
@@ -1103,8 +1079,8 @@ amcostestimate (PlannerInfo *root,
11031079
knowledge, use the standard optimizer function <function>clauselist_selectivity()</function>:
11041080

11051081
<programlisting>
1106-
*indexSelectivity = clauselist_selectivity(root,indexQuals,
1107-
index-&gt;rel-&gt;relid,
1082+
*indexSelectivity = clauselist_selectivity(root,path-&gt;indexquals,
1083+
path-&gt;indexinfo-&gt;rel-&gt;relid,
11081084
JOIN_INNER, NULL);
11091085
</programlisting>
11101086
</para>
@@ -1115,7 +1091,8 @@ amcostestimate (PlannerInfo *root,
11151091
Estimate the number of index rows that will be visited during the
11161092
scan. For many index types this is the same as <parameter>indexSelectivity</> times
11171093
the number of rows in the index, but it might be more. (Note that the
1118-
index's size in pages and rows is available from the <structname>IndexOptInfo</> struct.)
1094+
index's size in pages and rows is available from the
1095+
<literal>path-&gt;indexinfo</> struct.)
11191096
</para>
11201097
</step>
11211098

@@ -1137,7 +1114,7 @@ amcostestimate (PlannerInfo *root,
11371114
* Also, we charge for evaluation of the indexquals at each index row.
11381115
* All the costs are assumed to be paid incrementally during the scan.
11391116
*/
1140-
cost_qual_eval(&amp;index_qual_cost,indexQuals, root);
1117+
cost_qual_eval(&amp;index_qual_cost,path-&gt;indexquals, root);
11411118
*indexStartupCost = index_qual_cost.startup;
11421119
*indexTotalCost = seq_page_cost * numIndexPages +
11431120
(cpu_index_tuple_cost + index_qual_cost.per_tuple) * numIndexTuples;

‎src/backend/access/nbtree/nbtutils.c

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -616,7 +616,7 @@ _bt_advance_array_keys(IndexScanDesc scan, ScanDirection dir)
616616
*
617617
* The output keys must be sorted by index attribute. Presently we expect
618618
* (but verify) that the input keys are already so sorted --- this is done
619-
* bygroup_clauses_by_indexkey() in indxpath.c. Some reordering of the keys
619+
* bymatch_clauses_to_index() in indxpath.c. Some reordering of the keys
620620
* within each attribute may be done as a byproduct of the processing here,
621621
* but no other code depends on that.
622622
*

‎src/backend/nodes/outfuncs.c

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1512,7 +1512,9 @@ _outIndexPath(StringInfo str, const IndexPath *node)
15121512
WRITE_NODE_FIELD(indexinfo);
15131513
WRITE_NODE_FIELD(indexclauses);
15141514
WRITE_NODE_FIELD(indexquals);
1515+
WRITE_NODE_FIELD(indexqualcols);
15151516
WRITE_NODE_FIELD(indexorderbys);
1517+
WRITE_NODE_FIELD(indexorderbycols);
15161518
WRITE_BOOL_FIELD(isjoininner);
15171519
WRITE_ENUM_FIELD(indexscandir,ScanDirection);
15181520
WRITE_FLOAT_FIELD(indextotalcost,"%.2f");

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

Lines changed: 20 additions & 30 deletions
Original file line numberDiff line numberDiff line change
@@ -52,7 +52,9 @@
5252
* results into. All the input data they need is passed as separate
5353
* parameters, even though much of it could be extracted from the Path.
5454
* An exception is made for the cost_XXXjoin() routines, which expect all
55-
* the non-cost fields of the passed XXXPath to be filled in.
55+
* the non-cost fields of the passed XXXPath to be filled in, and similarly
56+
* cost_index() assumes the passed IndexPath is valid except for its output
57+
* values.
5658
*
5759
*
5860
* Portions Copyright (c) 1996-2011, PostgreSQL Global Development Group
@@ -208,38 +210,28 @@ cost_seqscan(Path *path, PlannerInfo *root,
208210
* cost_index
209211
* Determines and returns the cost of scanning a relation using an index.
210212
*
211-
* 'index' is the index to be used
212-
* 'indexQuals' is a list of lists of applicable qual clauses (implicit AND
213-
*semantics, one sub-list per index column)
214-
* 'indexOrderBys' is a list of lists of lists of ORDER BY expressions for
215-
*amcanorderbyop indexes (lists per pathkey and index column)
216-
* 'indexonly' is true if it's an index-only scan
213+
* 'path' describes the indexscan under consideration, and is complete
214+
*except for the fields to be set by this routine
217215
* 'outer_rel' is the outer relation when we are considering using the index
218-
*scan as the inside of a nestloop join (hence, some of theindexQuals
216+
*scan as the inside of a nestloop join (hence, some of theindexquals
219217
*are join clauses, and we should expect repeated scans of the index);
220218
*NULL for a plain index scan
221219
*
222-
*cost_index() takes an IndexPath not just a Path, because itsetsa few
223-
*additional fields of the IndexPath besides startup_cost and total_cost.
224-
*These fields are needed ifthe IndexPath is used in a BitmapIndexScan.
220+
*In addition to startup_cost and total_cost, cost_index()setsthe path's
221+
*indextotalcost and indexselectivity fields. These values are needed if
222+
* the IndexPath is used in a BitmapIndexScan.
225223
*
226-
* indexQuals is a list of lists of RestrictInfo nodes, but indexOrderBys
227-
* is a list of lists of lists of bare expressions.
228-
*
229-
* NOTE: 'indexQuals' must contain only clauses usable as index restrictions.
230-
* Any additional quals evaluated as qpquals may reduce the number of returned
231-
* tuples, but they won't reduce the number of tuples we have to fetch from
232-
* the table, so they don't reduce the scan cost.
224+
* NOTE: path->indexquals must contain only clauses usable as index
225+
* restrictions. Any additional quals evaluated as qpquals may reduce the
226+
* number of returned tuples, but they won't reduce the number of tuples
227+
* we have to fetch from the table, so they don't reduce the scan cost.
233228
*/
234229
void
235-
cost_index(IndexPath*path,PlannerInfo*root,
236-
IndexOptInfo*index,
237-
List*indexQuals,
238-
List*indexOrderBys,
239-
boolindexonly,
240-
RelOptInfo*outer_rel)
230+
cost_index(IndexPath*path,PlannerInfo*root,RelOptInfo*outer_rel)
241231
{
232+
IndexOptInfo*index=path->indexinfo;
242233
RelOptInfo*baserel=index->rel;
234+
boolindexonly= (path->path.pathtype==T_IndexOnlyScan);
243235
Coststartup_cost=0;
244236
Costrun_cost=0;
245237
CostindexStartupCost;
@@ -271,11 +263,9 @@ cost_index(IndexPath *path, PlannerInfo *root,
271263
* the fraction of main-table tuples we will have to retrieve) and its
272264
* correlation to the main-table tuple order.
273265
*/
274-
OidFunctionCall9(index->amcostestimate,
266+
OidFunctionCall7(index->amcostestimate,
275267
PointerGetDatum(root),
276-
PointerGetDatum(index),
277-
PointerGetDatum(indexQuals),
278-
PointerGetDatum(indexOrderBys),
268+
PointerGetDatum(path),
279269
PointerGetDatum(outer_rel),
280270
PointerGetDatum(&indexStartupCost),
281271
PointerGetDatum(&indexTotalCost),
@@ -431,7 +421,7 @@ cost_index(IndexPath *path, PlannerInfo *root,
431421
{
432422
QualCostindex_qual_cost;
433423

434-
cost_qual_eval(&index_qual_cost,indexQuals,root);
424+
cost_qual_eval(&index_qual_cost,path->indexquals,root);
435425
/* any startup cost still has to be paid ... */
436426
cpu_per_tuple-=index_qual_cost.per_tuple;
437427
}
@@ -589,7 +579,7 @@ get_indexpath_pages(Path *bitmapqual)
589579
* 'baserel' is the relation to be scanned
590580
* 'bitmapqual' is a tree of IndexPaths, BitmapAndPaths, and BitmapOrPaths
591581
* 'outer_rel' is the outer relation when we are considering using the bitmap
592-
*scan as the inside of a nestloop join (hence, some of theindexQuals
582+
*scan as the inside of a nestloop join (hence, some of theindexquals
593583
*are join clauses, and we should expect repeated scans of the table);
594584
*NULL for a plain bitmap scan
595585
*

0 commit comments

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