Latest Results
do not double validate the flatbuffer on the cuda layout (#6583)
<!--
Thank you for submitting a pull request! We appreciate your time and
effort.
Please make sure to provide enough information so that we can review
your pull
request. The Summary and Testing sections below contain guidance on what
to
include.
-->
## Summary
the cuda flat buffer layout is constructing an Array from both the
flatbuffer buffer, and potential overrides for some buffers that is
coming from the layout metadata. This currently only applies to constant
arrays, but previously we were double validating the flatbuffer. Now
ArrayParts support overrides and the cuda layout calls this new
constructor
<!--
If this PR is related to a tracked effort, please link to the relevant
issue
here (e.g., `Closes: #123`). Otherwise, feel free to ignore / delete
this.
In this section, please:
1. Explain the rationale for this change.
2. Summarize the changes included in this PR.
A general rule of thumb is that larger PRs should have larger summaries.
If
there are a lot of changes, please help us review the code by explaining
what
was changed and why.
If there is an issue or discussion attached, there is no need to
duplicate all
the details, but clarity is always preferred over brevity.
-->
Closes: #000
<!--
## API Changes
Uncomment this section if there are any user-facing changes.
Consider whether the change affects users in one of the following ways:
1. Breaks public APIs in some way.
2. Changes the underlying behavior of one of the engine integrations.
3. Should some documentation be updated to reflect this change?
If a public API is changed in a breaking manner, make sure to add the
appropriate label. You can run `./scripts/public-api.sh` locally to see
if there
are any public API changes (and this also runs in our CI).
-->
## Testing
<!--
Please describe how this change was tested. Here are some common
categories for
testing in Vortex:
1. Verifying existing behavior is maintained.
2. Verifying new behavior and functionality works correctly.
3. Serialization compatibility (backwards and forwards) should be
maintained or
explicitly broken.
-->
---------
Signed-off-by: Onur Satici <onur@spiraldb.com> increase default nvme coalescing (#6586)
<!--
Thank you for submitting a pull request! We appreciate your time and
effort.
Please make sure to provide enough information so that we can review
your pull
request. The Summary and Testing sections below contain guidance on what
to
include.
-->
## Summary
nvme coalescing config makes sense for raw nvme access, but we do all
our nvme reads through spawn_blocking, so we need more coalescing to
offset the overhead
<!--
If this PR is related to a tracked effort, please link to the relevant
issue
here (e.g., `Closes: #123`). Otherwise, feel free to ignore / delete
this.
In this section, please:
1. Explain the rationale for this change.
2. Summarize the changes included in this PR.
A general rule of thumb is that larger PRs should have larger summaries.
If
there are a lot of changes, please help us review the code by explaining
what
was changed and why.
If there is an issue or discussion attached, there is no need to
duplicate all
the details, but clarity is always preferred over brevity.
-->
Closes: #000
<!--
## API Changes
Uncomment this section if there are any user-facing changes.
Consider whether the change affects users in one of the following ways:
1. Breaks public APIs in some way.
2. Changes the underlying behavior of one of the engine integrations.
3. Should some documentation be updated to reflect this change?
If a public API is changed in a breaking manner, make sure to add the
appropriate label. You can run `./scripts/public-api.sh` locally to see
if there
are any public API changes (and this also runs in our CI).
-->
## Testing
<!--
Please describe how this change was tested. Here are some common
categories for
testing in Vortex:
1. Verifying existing behavior is maintained.
2. Verifying new behavior and functionality works correctly.
3. Serialization compatibility (backwards and forwards) should be
maintained or
explicitly broken.
-->
Signed-off-by: Onur Satici <onur@spiraldb.com> Active Branches
#65940%
#66080%
#6492×10
© 2026 CodSpeed Technology