Skip to content

Conversation

@Taepper
Copy link

@Taepper Taepper commented Jun 27, 2025

See #38584 for original PR. Will be quoted for this PR description.

Rationale for this change

support multi sortkey nulls first.

order by i nulls first, j, k nulls first;

The current null sorting only supports all sortkeys, not a certain sortkey, so NullPlacement is extended to the SortKey field. Since the underlying framework is very well written, when modifying this function, you only need to pass the null_placement of each SortKey in. That’s it.

What changes are included in this PR?

1.SortKey structure, NullPlacemnt transfer logic, sorting logic and Ording related, test related
2.Substriait related.
3.c_glib related.
4.SelectK related.
5.RankOptions related.

Are these changes tested?

yes, I changed the code inside vector_sort_test.cc and performed additional tests.

Are there any user-facing changes?

yes, pg database include null sorting of multiple sort keys.

This PR includes breaking changes to public APIs. (If there are any breaking changes to public APIs, please explain which changes are breaking. If not, you can remove this.)

I amended the original PR to be less breaking in public APIs.

Still Ordering, SortOptions, RankOptions, and RankQuantileOptions now accept a std::optional<NullPlacement> instead of NullPlacement, which did lead to some changes in downstream APIs and bindings. I also need some help with fixing the c_glib bindings.

Light-City and others added 30 commits November 9, 2023 09:57
1.Reconstruct the SortKey structure and add NullPlacement.

2.Remove NullPlacement from SortOptions

3.Fix selectk not displaying non-empty results in null AtEnd scenario.

When limit k is greater than the actual table data and the table contains Null/NaN, the data cannot be obtained and only non-empty results are available.
Therefore, we support returning non-null and supporting the order of setting Null for each SortKey.

4.Add relevant unit tests and change the interface implemented by multiple versions
…8558

# Conflicts:
#	c_glib/arrow-glib/compute.cpp
#	c_glib/arrow-glib/compute.h
#	cpp/src/arrow/compute/kernels/vector_rank.cc
#	cpp/src/arrow/compute/kernels/vector_select_k.cc
#	cpp/src/arrow/compute/kernels/vector_sort.cc
#	cpp/src/arrow/compute/kernels/vector_sort_internal.h
#	python/pyarrow/_acero.pyx
#	python/pyarrow/_compute.pyx
#	python/pyarrow/array.pxi
#	python/pyarrow/tests/test_compute.py
#	python/pyarrow/tests/test_table.py
# Conflicts:
#	cpp/src/arrow/compute/api_vector.cc
#	cpp/src/arrow/compute/api_vector.h
#	cpp/src/arrow/compute/kernels/vector_rank.cc
#	cpp/src/arrow/compute/kernels/vector_select_k.cc
#	cpp/src/arrow/compute/kernels/vector_sort.cc
#	cpp/src/arrow/compute/kernels/vector_sort_internal.h
#	cpp/src/arrow/compute/kernels/vector_sort_test.cc
#	cpp/src/arrow/compute/ordering.cc
#	cpp/src/arrow/compute/ordering.h
@github-actions github-actions bot added awaiting changes Awaiting changes and removed awaiting review Awaiting review labels Jan 23, 2026
@kou
Copy link
Member

kou commented Jan 23, 2026

Is not in the red-arrow ruby gem, but only in the GI bindings. Is this tolerable?

Yes. You're right.

I.e. are they only used for internal tests as the one I pasted, or are they part of arrow's published api?

They are part of published API like c_glib/*/*.{h,hpp}. But these API breakage are acceptable because we'll use "major version up" for the next release. "Major version up" means that we have API breakages in semantic versioning.

Sorry for my lack of knowledge in this regard

No problem. It's (a bit?) confusing...

Comment on lines +4405 to +4406
options->null_placement = garrow_optional_null_placement_to_raw(
static_cast<GArrowOptionalNullPlacement>(g_value_get_enum(value)));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you move them after the G_END_DECLS

G_END_DECLS
? We place exported C++ functions after G_END_DECLS.

…RROW_OPTIONAL_NULL_PLACEMENT_UNSPECIFIED correspond to -1. All other (possibly future) values will have a 1:1 mapping
…unctions in c_glib/arrow-glib/compute.{hpp,cpp}
@github-actions github-actions bot added awaiting change review Awaiting change review and removed awaiting changes Awaiting changes labels Jan 24, 2026
@github-actions github-actions bot added awaiting committer review Awaiting committer review awaiting changes Awaiting changes and removed awaiting change review Awaiting change review awaiting committer review Awaiting committer review awaiting changes Awaiting changes labels Jan 26, 2026
Copy link
Member

@kou kou left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1

@github-actions github-actions bot added awaiting change review Awaiting change review and removed awaiting changes Awaiting changes labels Jan 27, 2026
@kou
Copy link
Member

kou commented Jan 30, 2026

I'll merge this in a few days if nobody objects it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants