Skip to content

fix: Properly handle nulls in TopOrderable - #61

Merged
stuhood merged 6 commits into
mainfrom
stuhood.top-orderable-null-handling
Sep 3, 2025
Merged

fix: Properly handle nulls in TopOrderable#61
stuhood merged 6 commits into
mainfrom
stuhood.top-orderable-null-handling

Conversation

@stuhood

@stuhood stuhood commented Sep 3, 2025

Copy link
Copy Markdown
Collaborator

Adjusts Feature to use Option where necessary. StringFeature::SegmentOutput avoids being wrapped in an Option because the u64::MAX "niche" is safe to use in that case (since it would require that many terms to trigger a collision).

Surprisingly, no performance impact downstream.

@stuhood
stuhood force-pushed the stuhood.top-orderable-null-handling branch from bf16ca4 to 7daf4e0 Compare September 3, 2025 17:57
@stuhood

stuhood commented Sep 3, 2025

Copy link
Copy Markdown
Collaborator Author

Commits are useful to review independently: I additionally needed to adjust the unit tests to:

  1. include a NULL
  2. use a stable id, because for some reason at three segments (but not two?) the fact that segment ords are not stable was exposed.

@stuhood
stuhood merged commit 5b5ea75 into main Sep 3, 2025
5 checks passed
@stuhood
stuhood deleted the stuhood.top-orderable-null-handling branch September 3, 2025 18:14
stuhood added a commit that referenced this pull request Sep 3, 2025
Adjusts `Feature` to use `Option` where necessary. `StringFeature::SegmentOutput` avoids being wrapped in an `Option` because the `u64::MAX` "niche" is safe to use in that case (since it would require that many terms to trigger a collision).

Surprisingly, no performance impact downstream.

I additionally needed to adjust the unit tests to:
* include a NULL
* use a stable id, because for some reason at three segments (but not two?) the fact that segment ords are not stable was exposed.
stuhood added a commit that referenced this pull request Sep 3, 2025
Adjusts `Feature` to use `Option` where necessary. `StringFeature::SegmentOutput` avoids being wrapped in an `Option` because the `u64::MAX` "niche" is safe to use in that case (since it would require that many terms to trigger a collision).

Surprisingly, no performance impact downstream.

I additionally needed to adjust the unit tests to:
* include a NULL
* use a stable id, because for some reason at three segments (but not two?) the fact that segment ords are not stable was exposed.
stuhood added a commit to paradedb/paradedb that referenced this pull request Sep 3, 2025
## What

TopN was not handling nulls properly: instead, they were filled in with
a default, which would cause an error when the limit was high enough to
include them.

## How

See paradedb/tantivy#61.

## Tests

Added a regression test and property tests (which exposed a related
issue in pushdown: #3110).
github-actions Bot pushed a commit to paradedb/paradedb that referenced this pull request Sep 3, 2025
## What

TopN was not handling nulls properly: instead, they were filled in with
a default, which would cause an error when the limit was high enough to
include them.

## How

See paradedb/tantivy#61.

## Tests

Added a regression test and property tests (which exposed a related
issue in pushdown: #3110).
stuhood added a commit to paradedb/paradedb that referenced this pull request Sep 3, 2025
## What

TopN was not handling nulls properly: instead, they were filled in with
a default, which would cause an error when the limit was high enough to
include them.

## How

See paradedb/tantivy#61.

## Tests

Added a regression test and property tests (which exposed a related
issue in pushdown: #3110).

---------

Co-authored-by: Stu Hood <stuhood@paradedb.com>
Co-authored-by: Stu Hood <stuhood@gmail.com>
mdashti pushed a commit that referenced this pull request Oct 21, 2025
Adjusts `Feature` to use `Option` where necessary. `StringFeature::SegmentOutput` avoids being wrapped in an `Option` because the `u64::MAX` "niche" is safe to use in that case (since it would require that many terms to trigger a collision).

Surprisingly, no performance impact downstream.

I additionally needed to adjust the unit tests to:
* include a NULL
* use a stable id, because for some reason at three segments (but not two?) the fact that segment ords are not stable was exposed.
mdashti pushed a commit that referenced this pull request Oct 22, 2025
Adjusts `Feature` to use `Option` where necessary. `StringFeature::SegmentOutput` avoids being wrapped in an `Option` because the `u64::MAX` "niche" is safe to use in that case (since it would require that many terms to trigger a collision).

Surprisingly, no performance impact downstream.

I additionally needed to adjust the unit tests to:
* include a NULL
* use a stable id, because for some reason at three segments (but not two?) the fact that segment ords are not stable was exposed.
mdashti pushed a commit that referenced this pull request Oct 22, 2025
Adjusts `Feature` to use `Option` where necessary. `StringFeature::SegmentOutput` avoids being wrapped in an `Option` because the `u64::MAX` "niche" is safe to use in that case (since it would require that many terms to trigger a collision).

Surprisingly, no performance impact downstream.

I additionally needed to adjust the unit tests to:
* include a NULL
* use a stable id, because for some reason at three segments (but not two?) the fact that segment ords are not stable was exposed.
mdashti pushed a commit that referenced this pull request Dec 3, 2025
Adjusts `Feature` to use `Option` where necessary. `StringFeature::SegmentOutput` avoids being wrapped in an `Option` because the `u64::MAX` "niche" is safe to use in that case (since it would require that many terms to trigger a collision).

Surprisingly, no performance impact downstream.

I additionally needed to adjust the unit tests to:
* include a NULL
* use a stable id, because for some reason at three segments (but not two?) the fact that segment ords are not stable was exposed.
mdashti pushed a commit that referenced this pull request Dec 3, 2025
Adjusts `Feature` to use `Option` where necessary. `StringFeature::SegmentOutput` avoids being wrapped in an `Option` because the `u64::MAX` "niche" is safe to use in that case (since it would require that many terms to trigger a collision).

Surprisingly, no performance impact downstream.

I additionally needed to adjust the unit tests to:
* include a NULL
* use a stable id, because for some reason at three segments (but not two?) the fact that segment ords are not stable was exposed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants