> >> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
