Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
Greenplum
Gpdb
提交
47f18ec7
G
Gpdb
项目概览
Greenplum
/
Gpdb
通知
7
Star
1
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
DevOps
流水线
流水线任务
计划
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
G
Gpdb
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
DevOps
DevOps
流水线
流水线任务
计划
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
流水线任务
提交
Issue看板
体验新版 GitCode,发现更多精彩内容 >>
提交
47f18ec7
编写于
8月 13, 1999
作者:
T
Tom Lane
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
Update comments about pathkeys.
上级
8f9f6e51
变更
1
隐藏空白更改
内联
并排
Showing
1 changed file
with
63 addition
and
28 deletion
+63
-28
src/backend/optimizer/path/pathkeys.c
src/backend/optimizer/path/pathkeys.c
+63
-28
未找到文件。
src/backend/optimizer/path/pathkeys.c
浏览文件 @
47f18ec7
...
...
@@ -7,7 +7,7 @@
*
*
* IDENTIFICATION
* $Header: /cvsroot/pgsql/src/backend/optimizer/path/pathkeys.c,v 1.1
2 1999/07/16 04:59:15 momjian
Exp $
* $Header: /cvsroot/pgsql/src/backend/optimizer/path/pathkeys.c,v 1.1
3 1999/08/13 01:17:16 tgl
Exp $
*
*-------------------------------------------------------------------------
*/
...
...
@@ -33,18 +33,24 @@ static List *new_join_pathkey(List *pathkeys, List *join_rel_tlist,
* order of the result generated by the Path.
*
* In single/base relation RelOptInfo's, the Path's represent various ways
* of
generat
ing the relation and the resulting ordering of the tuples.
* of
scann
ing the relation and the resulting ordering of the tuples.
* Sequential scan Paths have NIL pathkeys, indicating no known ordering.
* Index scans have Path.pathkeys that represent the chosen index.
* A single-key index pathkeys would be { {tab1_indexkey1} }. For a
* multi-key index pathkeys would be { {tab1_indexkey1}, {tab1_indexkey2} },
* indicating major sort by indexkey1 and minor sort by indexkey2.
* Index scans have Path.pathkeys that represent the chosen index's ordering,
* if any. A single-key index would create a pathkey with a single sublist,
* e.g. ( (tab1_indexkey1) ). A multi-key index generates a sublist per key,
* e.g. ( (tab1_indexkey1) (tab1_indexkey2) ) which shows major sort by
* indexkey1 and minor sort by indexkey2.
*
* Note that a multi-pass indexscan (OR clause scan) has NIL pathkeys since
* we can say nothing about the overall order of its result. Also, an index
* scan on an unordered type of index generates no useful pathkeys. However,
* we can always create a pathkey by doing an explicit sort.
*
* Multi-relation RelOptInfo Path's are more complicated. Mergejoins are
* only performed with equijoins ("="). Because of this, the multi-relation
* path actually has more than one primary Var key. For example, a
* mergejoin Path of "tab1.col1 = tab2.col1" would generate
a
pathkeys of
*
{ {tab1.col1, tab2.col1} }
, indicating that the major sort order of the
* mergejoin Path of "tab1.col1 = tab2.col1" would generate pathkeys of
*
( (tab1.col1 tab2.col1) )
, indicating that the major sort order of the
* Path can be taken to be *either* tab1.col1 or tab2.col1.
* They are equal, so they are both primary sort keys. This allows future
* joins to use either Var as a pre-sorted key to prevent upper Mergejoins
...
...
@@ -53,21 +59,30 @@ static List *new_join_pathkey(List *pathkeys, List *join_rel_tlist,
* Note that while the order of the top list is meaningful (primary vs.
* secondary sort key), the order of each sublist is arbitrary.
*
* For multi-key sorts, if the outer is sorted by a multi-key index, the
* multi-key index remains after the join. If the inner has a multi-key
* sort, only the primary key of the inner is added to the result.
* Mergejoins only join on the primary key. Currently, non-primary keys
* in the pathkeys List are of limited value.
* We can actually keep all of the keys of the outer path of a merge or
* nestloop join, since the ordering of the outer path will be reflected
* in the result. We add to each pathkey sublist any inner vars that are
* equijoined to any of the outer vars in the sublist. In the nestloop
* case we have to be careful to consider only equijoin operators; the
* nestloop's join clauses might include non-equijoin operators.
* (Currently, we do this by considering only mergejoinable operators while
* making the pathkeys, since we have no separate marking for operators that
* are equijoins but aren't mergejoinable.)
*
* Although Hashjoins also work only with equijoin operators, it is *not*
* safe to consider the output of a Hashjoin to be sorted in any particular
* order --- not even the outer path's order. This is true because the
* executor might have to split the join into multiple batches.
* executor might have to split the join into multiple batches. Therefore
* a Hashjoin is always given NIL pathkeys.
*
* NestJoin does not perform sorting, and allows non-equijoins, so it does
* not allow useful pathkeys. (But couldn't we use the outer path's order?)
* Notice that pathkeys only say *what* is being ordered, and not *how*
* it is ordered. The actual sort ordering is indicated by a separate
* data structure, the PathOrder. The PathOrder provides a sort operator
* OID for each of the sublists of the path key. This is fairly bogus,
* since in cross-datatype cases we really want to keep track of more than
* one sort operator...
*
* -- bjm
* -- bjm
& tgl
*--------------------
*/
...
...
@@ -328,17 +343,32 @@ make_pathkeys_from_joinkeys(List *joinkeys,
/*
* new_join_pathkeys
* Find the path keys for a join relation by finding all vars in the list
* of join clauses 'joinclauses' such that:
* (1) the var corresponding to the outer join relation is a
* key on the outer path
* (2) the var appears in the target list of the join relation
* In other words, add to each outer path key the inner path keys that
* are required for qualification.
* Build the path keys for a join relation constructed by mergejoin or
* nestloop join. These keys should include all the path key vars of the
* outer path (since the join will retain the ordering of the outer path)
* plus any vars of the inner path that are mergejoined to the outer vars.
*
* Per the discussion at the top of this file, mergejoined inner vars
* can be considered path keys of the result, just the same as the outer
* vars they were joined with.
*
* We can also use inner path vars as pathkeys of a nestloop join, but we
* must be careful that we only consider equijoin clauses and not general
* join clauses. For example, "t1.a < t2.b" might be a join clause of a
* nestloop, but it doesn't result in b acquiring the ordering of a!
* joinpath.c handles that problem by only passing this routine clauses
* that are marked mergejoinable, even if a nestloop join is being built.
* Therefore we only have 't1.a = t2.b' style clauses, and can expect that
* the inner var will acquire the outer's ordering no matter which join
* method is actually used.
*
* All vars in the result are copied from the join relation's tlist, not from
* the given pathkeys or the join clauses. (Is that necessary? I suspect
* not --- tgl)
*
* 'outer_pathkeys' is the list of the outer path's path keys
* 'join_rel_tlist' is the target list of the join relation
* 'joinclauses' is the list of
restricting
join clauses
* 'joinclauses' is the list of
mergejoinable
join clauses
*
* Returns the list of new path keys.
*
...
...
@@ -358,8 +388,13 @@ new_join_pathkeys(List *outer_pathkeys,
new_pathkey
=
new_join_pathkey
(
outer_pathkey
,
join_rel_tlist
,
joinclauses
);
if
(
new_pathkey
!=
NIL
)
final_pathkeys
=
lappend
(
final_pathkeys
,
new_pathkey
);
/* if we can find no sortable vars for the n'th sort key,
* then we're done generating pathkeys; can't expect to order
* subsequent vars. Not clear that this can really happen.
*/
if
(
new_pathkey
==
NIL
)
break
;
final_pathkeys
=
lappend
(
final_pathkeys
,
new_pathkey
);
}
return
final_pathkeys
;
}
...
...
@@ -372,7 +407,7 @@ new_join_pathkeys(List *outer_pathkeys,
* at the top of this file).
*
* Note that each returned pathkey is the var node found in
* 'join_rel_tlist' rather than the joinclause var node.
* 'join_rel_tlist' rather than the
input pathkey or
joinclause var node.
* (Is this important?) Also, we return a fully copied list
* that does not share any subnodes with existing data structures.
* (Is that important, either?)
...
...
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录