Skip to content

Conversation

@analytically
Copy link
Contributor

~320x faster NULL scanning with zero allocations.

Benchmark results:

  • NULL scan: 97 ns → 0.3 ns
  • Mixed (2 NULL / 5 cols): 199 ns → 5.5 ns
  • Memory: 48 B/op → 0 B/op per NULL

Adds 15 sentinel error variables (~800 bytes total, allocated once at startup) for common NULL-into-non-pointer scan errors. Non-NULL error paths unchanged.

Also fixes uintWrapper.ScanInt64 error message (*uint64 → *uint).

~320x faster NULL scanning with zero allocations.

Benchmark results:
- NULL scan: 97 ns → 0.3 ns
- Mixed (2 NULL / 5 cols): 199 ns → 5.5 ns
- Memory: 48 B/op → 0 B/op per NULL

Adds 15 sentinel error variables (~800 bytes total, allocated once
at startup) for common NULL-into-non-pointer scan errors. Non-NULL
error paths unchanged.

Also fixes uintWrapper.ScanInt64 error message (*uint64 → *uint).

Signed-off-by: Mathias Bogaert <mathias.bogaert@gmail.com>
@jackc
Copy link
Owner

jackc commented Jan 1, 2026

Is there a case where this has a real world impact? It's optimizing an error path that should only be triggered by application bugs.

@analytically
Copy link
Contributor Author

analytically commented Jan 2, 2026

Impacts:

  • Nullable columns, scanned into non-pointers, many NULLs
  • LEFT JOINs scanned into non-pointers

It's a low-risk change with occasional high payoff.

@jackc
Copy link
Owner

jackc commented Jan 4, 2026

If you are scanning something that can be null into a Go value that can't accept it, that is an application bug. That is not a path to optimize that is behavior that needs to be fixed in the application.

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