update pathkey description.

diff --git a/src/backend/optimizer/path/pathkeys.c b/src/backend/optimizer/path/pathkeys.c
index 29f11dcd1c425ce242c6acc3f79aa119e0c90595..e19eeec01ff048e2b1cbcb2e35a347868a9f09e7 100644 (file)
--- 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