#include "optimizer/joininfo.h"
#include "optimizer/ordering.h"
-
static int match_pathkey_joinkeys(List *pathkey, List *joinkeys,
int outer_or_inner);
static bool joinkeys_pathkeys_match(List *joinkeys, List *pathkey,
static List *new_matching_subkeys(Var *subkey, List *considered_subkeys,
List *join_rel_tlist, List *joinclauses);
+
+/*
+ * Explanation of Path.pathkeys
+ *
+ * This structure 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
+ * of generate the relation. Sequential scan Paths have a NIL pathkeys.
+ * Index scans have Path.pathkeys that represent the chosen index. A
+ * single-key index pathkeys would be { {tab1_indexkey1} }. The pathkeys
+ * entry for a multi-key index would be { {tab1_indexkey1}, {tab1_indexkey2} }.
+ *
+ * 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
+ * { {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
+ * is a List of Lists.
+ */
+
/****************************************************************************
* KEY COMPARISONS
****************************************************************************/