update pathkey description.

bmomjian · bmomjian · commit 148ec3b1d888 · 1999-02-20T16:32:35.000Z
diff --git a/src/backend/optimizer/path/pathkeys.c b/src/backend/optimizer/path/pathkeys.c
@@ -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

Original file line number	Diff line number	Diff line change
`@@ -7,7 +7,7 @@`
`7`	`7`	`*`
`8`	`8`	`*`
`9`	`9`	`* IDENTIFICATION`
`10`		`- * $Header: /cvsroot/pgsql/src/backend/optimizer/path/pathkeys.c,v 1.2 1999/02/20 16:28:20 momjian Exp $`
	`10`	`+ * $Header: /cvsroot/pgsql/src/backend/optimizer/path/pathkeys.c,v 1.3 1999/02/20 16:32:35 momjian Exp $`
`11`	`11`	`*`
`12`	`12`	`*-------------------------------------------------------------------------`
`13`	`13`	`*/`
`@@ -38,7 +38,7 @@ static List new_matching_subkeys(Var subkey, List *considered_subkeys,`
`38`	`38`	`/*`
`39`	`39`	`* Explanation of Path.pathkeys`
`40`	`40`	`*`
`41`		`- * This structure is a List of List of Var nodes that represent the sort`
	`41`	`+ * Path.pathkeys is a List of List of Var nodes that represent the sort`
`42`	`42`	`* order of the result generated by the Path.`
`43`	`43`	`*`
`44`	`44`	`* 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,`
`49`	`49`	`*`
`50`	`50`	`* Multi-relation RelOptInfo Path's are more complicated. Mergejoins are`
`51`	`51`	`* only performed with equajoins("="). Because of this, the multi-relation`
`52`		`- * path actually has more than one ordering. For example, a mergejoin Path`
`53`		`- * of "tab1.col1 = tab2.col1" would generate a pathkeys of`
	`52`	`+ * path actually has more than one primary Var key. For example, a`
	`53`	`+ * mergejoin Path of "tab1.col1 = tab2.col1" would generate a pathkeys of`
`54`	`54`	`* { {tab1.col1, tab2.col1} }. This allows future joins to use either Var`
`55`	`55`	`* as a pre-sorted key to prevent Mergejoins from having to re-sort the Path.`
`56`	`56`	`* They are equal, so they are both primary sort keys. This is why pathkeys`