BUG: Index.join different sorting behavior in libjoin faspath

[jbrockmendel]

In Index we have a _can_use_libjoin check that determined if we can use the libjoin fastpaths (AFAICT these are just fastpaths and the behavior is supposed to be identical to the non-fastpaths). There are a few cases where _can_use_libjoin is not strict enough and we end up making copies in order to use the fastpaths, which negates the benefits (havent actually done any measurements, just assuming). In particular MultiIndex and RangeIndex cases.

Patching can_use_libjoin to return False in MultiIndex and RangeIndex cases breaks a bunch of tests bc the join results cease to be ordered. Needs further investigation.

[lukemanley]

Any idea if #54611 helps here?

[jbrockmendel]

Based on a quick look I’m optimistic

[jbrockmendel]

@lukemanley was this closed by #54765?

[lukemanley]

@lukemanley was this closed by #54765?

#54765 addressed the MultiIndex case. The RangeIndex case is still outstanding. I don't recall the specifics, but I think the RangeIndex case required a bit more refactoring.

[rhshadrach]

Is this related to this comment?

pandas/pandas/core/indexes/base.py

Lines 4662 to 4665 in 7b8c6f6

	elif how == "outer":
	# TODO: sort=True here for backwards compat. It may
	# be better to use the sort parameter passed into join
	join_index = self.union(other)

Bumped into the comment above and will link to this issue if it is.

[jbrockmendel]

definitely looks related, yes