fix: ml.model_selection.train_test_split index to match in unordered mode

[GarrettWu]

Thank you for opening a Pull Request! Before submitting your PR, there are a few things you can do to make sure it goes smoothly:

• Make sure to open an issue as a bug/issue before writing your code! That way we can discuss the change, evaluate designs, and agree on the general idea
• Ensure the tests and linter pass
• Code coverage does not decrease (if any source code was changed)
• Appropriate docs were updated (if necessary)

Fixes b/462105877

[TrevorBergeron]

This is a lot of .cache() calls. I think where the caching ideally happens is actually inside the block.split method. This way, the ordering is locked in, but only a single table is cached total, which should be a lot faster.

[GarrettWu]

I can put the caches outside of the loop, which removes some queries. But otherwise (caching anywhere in block.split) it doesn't work. Do you have an insight why is it?

[TrevorBergeron]

hmm, really? would expect caching anywhere around this area:

python-bigquery-dataframes/bigframes/core/blocks.py

Lines 901 to 913 in b487cf1

	block, string_ordering_col=block.apply_unary_op(
	ordering_col, ops.AsTypeOp(to_type=bigframes.dtypes.STRING_DTYPE)
	)
	# Apply hash method to sum col and order by it.
	block, string_sum_col=block.apply_binary_op(
	string_ordering_col, random_state_col, ops.strconcat_op
	)
	block, hash_string_sum_col=block.apply_unary_op(string_sum_col, ops.hash_op)
	block=block.order_by(
	[ordering.OrderingExpression(ex.deref(hash_string_sum_col))]
	)

would work ok (ideally at the end of this block).

[GarrettWu]

No, no matter where, within the block.split, it won't work. Only do a cache() to the end results would help.

screen/6A2RFRNf9m96Qvo

Would it be a bug in some deeper code?