Like lookupsIO, but takes a write buffer into account.

Batched lookups in I/O.

PRECONDITION: the vectors of bloom filters, indexes and file handles should pointwise match with the vectors of runs.

The table data is corrupted.

A RunIxKeyIx is a (compact) pair of a RunIx and a KeyIx.

We represent it as a 32bit word, using:

• 16 bits for the run/filter index (MSB)
• 16 bits for the key index (LSB)

Prepare disk lookups by doing bloom filter queries, index searches and creating IOOps. The result is a vector of IOOps and a vector of indexes, both of which are the same length. The indexes record the run and key associated with each IOOp.

Perform a batch of bloom queries. The result is a tuple of indexes into the vector of runs and vector of keys respectively. The order of keys and runs/filters in the input is maintained in the output. This implementation produces results in key-major order.

The result vector can be of variable length. The initial estimate is 2x the number of keys but this is grown if needed (using a doubling strategy).

Perform a batch of fence pointer index searches, and create an IOOp for each search result. The resulting vector has the same length as the VP.Vector RunIxKeyIx argument, because index searching always returns a positive search result.

Like intraPageLookupsOn, but uses the write buffer as the initial accumulator.

Intra-page lookups, and combining lookup results from multiple runs and a potential initial accumulator (e.g. from the write buffer).

This function assumes that rkixs is ordered such that newer runs are handled first. The order matters for resolving cases where we find the same key in multiple runs.