77 *
88 *
99 * 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 $
1111 *
1212 *-------------------------------------------------------------------------
1313 */
@@ -38,7 +38,7 @@ static List *new_matching_subkeys(Var *subkey, List *considered_subkeys,
3838/*
3939 *Explanation of Path.pathkeys
4040 *
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
4242 *order of the result generated by the Path.
4343 *
4444 *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,
4949 *
5050 *Multi-relation RelOptInfo Path's are more complicated. Mergejoins are
5151 *only performed with equajoins("="). Because of this, the multi-relation
52- *path actually has more than oneordering . For example, a mergejoin Path
53- *of "tab1.col1 = tab2.col1" would generate a pathkeys of
52+ *path actually has more than oneprimary Var key . For example, a
53+ *mergejoin Path of "tab1.col1 = tab2.col1" would generate a pathkeys of
5454 *{ {tab1.col1, tab2.col1} }. This allows future joins to use either Var
5555 *as a pre-sorted key to prevent Mergejoins from having to re-sort the Path.
5656 *They are equal, so they are both primary sort keys. This is why pathkeys