>
>> If the inner and/or outer paths are not ordered as required, we will need
>> to
>> order them. Code below doesn't seem to handle that case.
>> /*
>> * If the paths are already well enough ordered, we
>> can
>> * skip doing an explicit sort.
>> */
>> if (outerkeys &&
>> pathkeys_contained_in(outerkeys,
>> outer_path->pathkeys))
>> outerkeys = NIL;
>> if (innerkeys &&
>> pathkeys_contained_in(innerkeys,
>> inner_path->pathkeys))
>> innerkeys = NIL;
>
>
> I might be missing something, but if the outer/inner paths are already well
> sorted, we wouldn't need an explicit sort, so we can set the
> outerkeys/innerkeys to NIL safely. (You can find the same optimization in
> try_mergejoin_path.)
Actually I didn't notice that create_mergejoin_path saves those keys
in the MergePath and then adds sorting steps during planning. Sorry
for the trouble.
Another concern here is that we are copying pieces of logic in
add_paths_to_joinrel() without arranging it as neatly as in that
function.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company