[dfa1]

WHERE col = 'x' on a dictionary-encoded string column already evaluated the predicate once per dictionary value (#552). Profiling a 100M-row file showed where the rest of the time went. Four changes follow Rust's dict reader, in one commit:

1. Bulk row mask. u8/u16 codes are mapped to a row bitmap in one pass over their segment, Rust's values.take(codes). This replaces a per-row VarBinDictArray.code(i) call (216 of 616 samples). The loop is chosen once per chunk, from three shapes:

   • no value matches: only the largest code is checked, with the vectorized max kernel;
   • exactly one matches: each code is compared with that value's code, a branch taken only on matching rows;
   • several match: a branch-free lookup table.

   A code outside the dictionary falls back to the per-row path, which reports it.

2. One evaluation per dictionary. The new Compute.matcher(RowFilter) keeps the per-value results across a scan's chunks, as Rust caches its values evaluation. The Calcite callers now use it.

3. No extra pass over the codes. A pool no longer than its codes is walked whole. Only a constant pool or a longer one still needs the scan (checkedPoolExtent) that read every code just to bound the walk.

4. Prune when no value matches. ScanIterator skips a dict layout's chunks when no dictionary value satisfies a filter that rejects nulls. This is decided from the values alone, once per dictionary.

   • Deliberate divergence: Rust always reads the codes, so here a corrupt codes buffer under such a filter goes unreported. Recorded in docs/compatibility.md.

100M-row file through the jdbc:vortex: driver, warm JVM, median of the last 8 of 15 runs:

query	before	after
count(*) where ISIN = 'ZZYRS9DBOAM3'	293 ms	145 ms
count(*) where ISIN = 'NOPE'	292 ms	9 ms (nothing scanned)
select eventIdentifier where ISIN = …	386 ms	222 ms
select * where ISIN = …	790 ms	633 ms
count(*) where taxCountry = 'XX'	107 ms	9 ms

YourKit, 15 runs of the first query: the per-row test took 3,400 ms before; building the bitmap now takes 620 ms.

What's left is unpacking the bit-packed codes once, which Rust pays too.

Also fixed

• Negative codes: a negative 64-bit code into a nullable pool now fails with VortexException. Skipping the code scan had exposed a raw IndexOutOfBoundsException here, and flat pools already hit it on main.
• Pruning test count: pruning now tests every value that actually decodes, not the count the layout claims. A malformed file could otherwise prune a chunk with matching rows.

Tests

• ComputeTest:

  • matcher cases over U8, U16 and I32 codes
  • a u8 dictionary longer than 256 entries
  • the memo reusing a shared dictionary

• ScanIteratorDictPruningTest covers the pruning rules:

  • AND / OR / IS NULL / IS NOT NULL / <>
  • null dictionary values
  • a pool decoding longer than it claims
  • the size guard
  • malformed values

• DictLayoutDecoderTest:

  • the negative code
  • a code past a pool walked whole

• DictFilterInteropIntegrationTest filters four files against a plain Java check of the written rows:

  • vortex-jni, 4 values
  • vortex-jni, 300 values
  • vortex-java, default write
  • vortex-java per-chunk dictionary, which is the case with u8 codes

  A missing value must skip every chunk of the three dict layouts; that test fails with pruning disabled.

• ./mvnw verify passes (9188 tests).

🤖 Generated with Claude Code