Skip to content

feat: elias-fano encoding - #9935

Open
rapour wants to merge 1 commit into
vortex-data:developfrom
rapour:feat/elias-fano-phase-1-encoding
Open

rapour wants to merge 1 commit into
vortex-data:developfrom
rapour:feat/elias-fano-phase-1-encoding

Conversation

@rapour

@rapour rapour commented Sep 18, 2026

Copy link
Copy Markdown
Contributor

Rationale for this change

This PR introduces a new encoding: Non-partitioned Elias-Fano for weakly monotonic sequences. The changes include the encoding itself plus slice reduce rule.

What changes are included in this PR?

The following decisions, subject to further discussion, have affected the implementation:

  • Non-partitioned only. The partitioned/quasi-succinct variant is left out entirely for the sake of simplicity. It can be added later.

  • Non-nullable. Currently the implementation only accepts non-nullable sequences. We can probably switch to accept them and persist a third validity buffer.

  • Sampled select rather than a full rank/select directory. The encoder stores the absolute position of every 256th set bit and every 512th unset bit, so a lookup jumps to the nearest signpost and finishes with a popcount walk bounded to one or two 64-byte blocks, for well under half a bit per value. We can switch to more complex rand/select directories based solutions like RsVec but the performance trade-offs needs investigation.

  • An Elias-Fano array is encoded once, over a whole sequence, and every position inside it is absolute: element 500's bits sit at a fixed place in the buffers no matter which part of the array you are looking at. first_rank is just the offset saying which element of that original sequence this array's row 0 corresponds to. So slicing 1000..2000 out of a million-element array copies nothing. It sets first_rank = 1000 and the length to 1000, and reuses the original buffers unchanged; reading row 0 of the slice reads element 1000 underneath, row 1 reads element 1001, and so on. The trade-off is that the slice still carries the entire encoded sequence, in memory and on disk. Those unused rows only go away when the array is written out again.

  • One 64-bit path serves every integer width. Each value widens to u64 on the way in and has the reference subtracted; on the way out the reference is added back and the result narrows to the column's own width. Both steps use wrapping arithmetic, which is what makes them exact for signed columns as well as unsigned, so i8 through u64 share one encoder, and decoder instead of getting one each. The column's type is consulted only at those two edges, so nothing in the per-element loop branches on it.

What APIs are changed? Are there any user-facing changes?

Additive only. No behaviour changes.

Disclosure:
Claude code has implemented parts of the code, specially vortex-specific handles, comments, and tests, and improved others and has reviewed the implementation multiple times.

@rapour
rapour force-pushed the feat/elias-fano-phase-1-encoding branch from cfabcc2 to 6043f1a Compare September 18, 2026 11:41
Signed-off-by: rapour <reza.apour@gmail.com>
@rapour
rapour force-pushed the feat/elias-fano-phase-1-encoding branch from 6043f1a to 9d3bd7d Compare September 18, 2026 11:43
@codspeed

codspeed Bot commented Sep 18, 2026

Copy link
Copy Markdown

Merging this PR will improve performance by 13.79%

⚠️ Unknown Walltime execution environment detected

Using the Walltime instrument on standard Hosted Runners will lead to inconsistent data.

For the most accurate results, we recommend using CodSpeed Macro Runners: bare-metal machines fine-tuned for performance measurement consistency.

⚡ 1 improved benchmark
✅ 2204 untouched benchmarks
⏩ 218 skipped benchmarks1

Performance Changes

Mode Benchmark BASE HEAD Efficiency
WallTime words_gather_scalar_avx2[65536] 9.4 µs 8.2 µs +13.79%

Tip

Curious why performance improved? Comment @codspeedbot explain why performance improved on this PR, or directly use the CodSpeed MCP with your agent.


Comparing rapour:feat/elias-fano-phase-1-encoding (9d3bd7d) with develop (75b6225)

Open in CodSpeed

Footnotes

  1. 218 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports.

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.

1 participant