diff options
author | Tom Lane | 2011-12-25 00:03:21 +0000 |
---|---|---|
committer | Tom Lane | 2011-12-25 00:03:21 +0000 |
commit | 472d3935a2793343e450ba7cda4adbc323a984c3 (patch) | |
tree | 30fc6e85cc76a7b48ff84243237ccdc1dd41a00b /src/include/nodes/relation.h | |
parent | e2c2c2e8b1df7dfdb01e7e6f6191a569ce3c3195 (diff) |
In commit e2c2c2e8b1df7dfdb01e7e6f6191a569ce3c3195 I made use of nested
list structures to show which clauses went with which index columns, but
on reflection that's a data structure that only an old-line Lisp hacker
could love. Worse, it adds unnecessary complication to the many places
that don't much care which clauses go with which index columns. Revert
to the previous arrangement of flat lists of clauses, and instead add a
parallel integer list of column numbers. The places that care about the
pairing can chase both lists with forboth(), while the places that don't
care just examine one list the same as before.
The only real downside to this is that there are now two more lists that
need to be passed to amcostestimate functions in case they care about
column matching (which btcostestimate does, so not passing the info is not
an 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 seems
more future-proof against likely additions to the information we keep
about an index path.
Diffstat (limited to 'src/include/nodes/relation.h')
-rw-r--r-- | src/include/nodes/relation.h | 46 |
1 files changed, 27 insertions, 19 deletions
diff --git a/src/include/nodes/relation.h b/src/include/nodes/relation.h index b137142f3e..13018027b6 100644 --- a/src/include/nodes/relation.h +++ b/src/include/nodes/relation.h @@ -657,27 +657,33 @@ typedef struct Path * * 'indexclauses' is a list of index qualification clauses, with implicit * AND semantics across the list. Each clause is a RestrictInfo node from - * the query's WHERE or JOIN conditions. - * - * 'indexquals' is a list of sub-lists of the actual index qual conditions - * that can be used with the index. There is one possibly-empty sub-list - * for each index column (but empty sub-lists for trailing columns can be - * omitted). The qual conditions are RestrictInfos, and in simple cases - * are the same RestrictInfos that appear in the flat indexclauses list. - * But when special indexable operators appear in 'indexclauses', they are - * replaced by their derived indexscannable conditions in 'indexquals'. - * Note that an entirely empty indexquals list denotes a full-index scan. - * - * 'indexorderbys', if not NIL, is a list of lists of lists of ORDER BY - * expressions that have been found to be usable as ordering operators for an - * amcanorderbyop index. These are not RestrictInfos, just bare expressions, + * the query's WHERE or JOIN conditions. An empty list implies a full + * index scan. + * + * 'indexquals' has the same structure as 'indexclauses', but it contains + * the actual index qual conditions that can be used with the index. + * In simple cases this is identical to 'indexclauses', but when special + * indexable operators appear in 'indexclauses', they are replaced by the + * derived indexscannable conditions in 'indexquals'. + * + * 'indexqualcols' is an integer list of index column numbers (zero-based) + * of the same length as 'indexquals', showing which index column each qual + * is meant to be used with. 'indexquals' is required to be ordered by + * index column, so 'indexqualcols' must form a nondecreasing sequence. + * (The order of multiple quals for the same index column is unspecified.) + * + * 'indexorderbys', if not NIL, is a list of ORDER BY expressions that have + * been found to be usable as ordering operators for an amcanorderbyop index. + * The list must match the path's pathkeys, ie, one expression per pathkey + * in the same order. These are not RestrictInfos, just bare expressions, * since they generally won't yield booleans. Also, unlike the case for * quals, it's guaranteed that each expression has the index key on the left - * side of the operator. The top list has one entry per pathkey in the - * path's pathkeys, and the sub-lists have one sub-sublist per index column. - * This representation is a bit of overkill, since there will be only one - * actual expression per pathkey, but it's convenient because each sub-list - * has the same structure as the indexquals list. + * side of the operator. + * + * 'indexorderbycols' is an integer list of index column numbers (zero-based) + * of the same length as 'indexorderbys', showing which index column each + * ORDER BY expression is meant to be used with. (There is no restriction + * on which index column each ORDER BY can be used with.) * * 'isjoininner' is TRUE if the path is a nestloop inner scan (that is, * some of the index conditions are join rather than restriction clauses). @@ -711,7 +717,9 @@ typedef struct IndexPath IndexOptInfo *indexinfo; List *indexclauses; List *indexquals; + List *indexqualcols; List *indexorderbys; + List *indexorderbycols; bool isjoininner; ScanDirection indexscandir; Cost indextotalcost; |