11
11
* Portions Copyright (c) 1994, Regents of the University of California
14
* $PostgreSQL: pgsql/src/backend/optimizer/path/pathkeys.c,v 1.97 2009/02/28 03:51:05 tgl Exp $
14
* $PostgreSQL: pgsql/src/backend/optimizer/path/pathkeys.c,v 1.97.2.1 2009/07/17 23:19:59 tgl Exp $
16
16
*-------------------------------------------------------------------------
988
988
* no two members have the same EC, so it's not possible for this
989
989
* code to enter the same mergeclause into the result list twice.
991
* XXX it's possible that multiple matching clauses might have
992
* different ECs on the other side, in which case the order we put
993
* them into our result makes a difference in the pathkeys required
994
* for the other input path. However this routine hasn't got any info
995
* about which order would be best, so for now we disregard that case
996
* (which is probably a corner case anyway).
991
* It's possible that multiple matching clauses might have different
992
* ECs on the other side, in which case the order we put them into our
993
* result makes a difference in the pathkeys required for the other
994
* input path. However this routine hasn't got any info about which
995
* order would be best, so we don't worry about that.
997
* It's also possible that the selected mergejoin clauses produce
998
* a noncanonical ordering of pathkeys for the other side, ie, we
999
* might select clauses that reference b.v1, b.v2, b.v1 in that
1000
* order. This is not harmful in itself, though it suggests that
1001
* the clauses are partially redundant. Since it happens only with
1002
* redundant query conditions, we don't bother to eliminate it.
1003
* make_inner_pathkeys_for_merge() has to delete duplicates when
1004
* it constructs the canonical pathkeys list, and we also have to
1005
* deal with the case in create_mergejoin_plan().
999
1008
foreach(j, restrictinfos)