Description

This PR use col.info.get_sortable_arrays() in Table.argsort() for efficient mixin sorting. This fixes the first bullet point of #14942.

Rationale

Table.argsort() (and hence Table.sort()) currently sorts by converting the key columns to a NumPy array via Table.as_array(). For a single plain key column this is just the column data, but for multiple key columns it builds a structured array over all of them, and if any key is a mixin column (like ~astropy.time.Time) that can't be represented as native structured-array dtype, it gets stored as a slow Python object array. Every comparison during the sort then falls back to Python-level object comparisons instead of vectorized NumPy operations, which is extremely slow — see the benchmark below, where combining a Time column with a plain int column is over 1000x slower than sorting on the int column alone.

get_sortable_arrays() already exists as an info method (used internally by table joins) that returns one or more plain NumPy arrays which can be lexically sorted to reproduce the sort order of a column, without needing an object array. For a normal Column this is just [self.data]. For a Time column it is two float arrays (jd1/jd2 split into an approximate value and a remainder) that fully capture time ordering without loss of precision.

This PR reworks Table.argsort() to call get_sortable_arrays() on each key column and flatten the results into a single list of arrays. If there is only one sortable array overall (e.g. a single plain-column key), np.argsort is used directly, preserving support for the kind argument. Otherwise (multiple keys, and/or a mixin column that expands into multiple arrays) np.lexsort is used, which is always stable and does not accept kind; in that case a non-default, non-stable kind is ignored and triggers an AstropyUserWarning.

If a column's get_sortable_arrays() raises NotImplementedError (e.g. SkyCoord, which has no well-defined sort order), Table.argsort() now raises TypeError rather than falling through to a slow/incorrect object array comparison.

As part of this work, Time.info.get_sortable_arrays() was also optimized: it previously computed the remainder term by constructing a new Time object and subtracting, which is roughly as expensive as computing a full Time.argsort(). It now uses the same cheap jd1/jd2 float arithmetic that Time.argsort() already uses internally, avoiding that redundant object construction.

Changes

• astropy/table/table.py: Table.argsort() rewritten to use col.info.get_sortable_arrays() per key column, dispatching to np.argsort for a single sortable array or np.lexsort otherwise.
• astropy/time/core.py: TimeInfo.get_sortable_arrays() optimized to avoid constructing an intermediate Time object.
• astropy/table/tests/test_table.py: updated test_sort_kind for the new kind warning behavior on multi-key sorts, and added test_sort_kind_single_key covering the single-sortable-array code path for all numpy.argsort kind values.
• astropy/table/tests/test_operations.py: added regression tests for multi-key sorts involving a Time column, the kind warning on multi-key sorts, and the TypeError raised for non-sortable mixin columns (e.g. SkyCoord).
• docs/changes/table/20149.perf.rst: changelog entry.

Backwards compatibility notes

• Sorting on a column whose mixin does not support get_sortable_arrays() (raises NotImplementedError, e.g. SkyCoord) now raises TypeError instead of attempting (and likely failing or behaving incorrectly on) an object-array sort.

Performance

Table.argsort() performance: main vs table-unified-sort

Benchmark script: perf_test_argsort_time.py

N = 100,000 rows, 5 repeats per case, median times reported.

Results

Key findings

• Pure plain-column cases (single or multiple int columns) are roughly the same or a few times faster on this branch — the get_sortable_arrays() path avoids building a structured array via as_array().
• The catastrophic case is mixing a Time mixin column with a plain column on main: sorting ["time", "int"] forces as_array(names=keys), which converts the Time column into a structured array of Python objects, making every comparison during the sort go through slow object comparisons — over 1000x slower than this branch's approach of flattening get_sortable_arrays() and using np.lexsort directly on numeric arrays.
• This confirms the core motivation for gh-14942: mixin columns like Time combined with any other sort key were essentially unusable at scale on main.

AI disclosure

Essentially all of this PR was generated using GitHub CoPilot with Claude Sonnet 5. I reviewed everything carefully and understand all the changes.

• By checking this box, the PR author has requested that maintainers do NOT use the "Squash and Merge" button. Maintainers should respect this when possible; however, the final decision is at the discretion of the maintainer that merges the PR.