mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

update pathkey description.

Browse Source
This commit is contained in:
Bruce Momjian 1999-02-20 16:32:35 +00:00
parent 9188aab758
commit 148ec3b1d8
1 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
src/backend/optimizer/path/pathkeys.c
View File

@ -7,7 +7,7 @@
*
*
* IDENTIFICATION
* $Header: /cvsroot/pgsql/src/backend/optimizer/path/pathkeys.c,v 1.2 1999/02/20 16:28:20 momjian Exp $
* $Header: /cvsroot/pgsql/src/backend/optimizer/path/pathkeys.c,v 1.3 1999/02/20 16:32:35 momjian Exp $
*
*-------------------------------------------------------------------------
*/
@ -38,7 +38,7 @@ static List *new_matching_subkeys(Var *subkey, List *considered_subkeys,
/*
* Explanation of Path.pathkeys
*
* This structure is a List of List of Var nodes that represent the sort
* Path.pathkeys is a List of List of Var nodes that represent the sort
* order of the result generated by the Path.
*
* In single/base relation RelOptInfo's, the Path's represent various ways
@ -49,8 +49,8 @@ static List *new_matching_subkeys(Var *subkey, List *considered_subkeys,
*
* Multi-relation RelOptInfo Path's are more complicated. Mergejoins are
* only performed with equajoins("="). Because of this, the multi-relation
* path actually has more than one ordering. For example, a mergejoin Path
* of "tab1.col1 = tab2.col1" would generate a pathkeys of
* 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} }. This allows future joins to use either Var
* as a pre-sorted key to prevent Mergejoins from having to re-sort the Path.
* They are equal, so they are both primary sort keys. This is why pathkeys