El 22/02/18 a las 21:03, Tom Lane escribió:
The third possibility is to decide that create_mergejoin_plan is being
overly paranoid and it's okay to extract merge details from a "redundant"
path key even though it specifies the opposite sort order from what the
current merge clause seems to need.
This check looks necessary to me, because merge join can't work with
such a combination of outer pathkeys and merge clauses. The order of
outer and inner column must be the same. Here, two outer columns with
different orders are compared to the same inner column, so there will be
mismatch one way or another. Consider the original query with some
desc asc desc
i2 k2 i1
-> 1 0 1 <-
1 1 0
The merge join starts at tuples marked with arrows. It finds that the
outer tuple is less than the inner, so it advances the inner pointer,
and loses the tuple with i1 = 1.
So, if we can't do a merge join on these clauses with these pathkeys
anyway, it is OK to discard some of them in
find_mergeclauses_for_pathkey. This helps the case when we use the
existing order of outer relation. Also, we should take care not to
create such combinations in select_outer_pathkeys_for_merge, when it
tries to match root->query_pathkeys.
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company