On 24/03/25 11:10AM, Patrick Steinhardt wrote:
> When seeking a record in our block reader we perform a binary search
> over the block's restart points so that we don't have to do a linear
> scan over the whole block. The logic to do so is quite intricate though,
> which makes it hard to understand.
>
> Improve documentation and rename some of the functions and variables so
> that the code becomes easier to understand overall. This refactoring
> should not result in any change in behaviour.
>
> Signed-off-by: Patrick Steinhardt <ps@xxxxxx>
> ---
...
> - i = binsearch(br->restart_count, &restart_key_less, &args);
> + /*
> + * Perform a binary search over the block's restart points, which
> + * avoids doing a linear scan over the whole block. Like this, we
> + * identify the section of the block that should contain our key.
> + *
> + * Note that we explicitly search for the first restart point _greater_
> + * than the sought-after record, not _greater or equal_ to it. In case
> + * the sought-after record is located directly at the restart point we
> + * would otherwise start doing the linear search at the preceding
> + * restart point. While that works alright, we would end up scanning
> + * too many record.
> + */
> + i = binsearch(br->restart_count, &restart_needle_less, &args);
> +
> + /*
> + * Now there are multiple cases:
> + *
> + * - `i == 0`: The wanted record must be contained before the first
> + * restart point. We will thus start searching for the record in
> + * that section after accounting for the header offset.
To clarify my understanding, does a restart_offset not exist at the
beginning of a block? I was originally under the impression that the
first reset point would be at the beginning of the block (or just after
the header). If this was the case, the first restart point being greater
would indicate that the wanted record is not contained within the block.
-Justin
> + *
> + * - `i == restart_count`: The wanted record was not found at any of
> + * the restart points. As there is no restart point at the end of
> + * the section the record may thus be contained in the last block.
> + *
> + * - `i > 0`: The wanted record must be contained in the section
> + * before the found restart point. We thus do a linear search
> + * starting from the preceding restart point.
> + */
> if (i > 0)
> it->next_off = block_reader_restart_offset(br, i - 1);
> else
> @@ -399,21 +429,34 @@ int block_reader_seek(struct block_reader *br, struct block_iter *it,
>
> reftable_record_init(&rec, block_reader_type(br));
>
> - /* We're looking for the last entry less/equal than the wanted key, so
> - we have to go one entry too far and then back up.
> - */
> + /*
> + * We're looking for the last entry less than the wanted key so that
> + * the next call to `block_reader_next()` would yield the wanted
> + * record. We thus don't want to position our reader at the sought
> + * after record, but one before. To do so, we have to go one entry too
> + * far and then back up.
> + */
> while (1) {
> block_iter_copy_from(&next, it);
> err = block_iter_next(&next, &rec);
> if (err < 0)
> goto done;
> -
> - reftable_record_key(&rec, &it->last_key);
> - if (err > 0 || strbuf_cmp(&it->last_key, want) >= 0) {
> + if (err > 0) {
> err = 0;
> goto done;
> }
>
> + /*
> + * Check whether the current key is greater or equal to the
> + * sought-after key. In case it is greater we know that the
> + * record does not exist in the block and can thus abort early.
> + * In case it is equal to the sought-after key we have found
> + * the desired record.
> + */
> + reftable_record_key(&rec, &it->last_key);
> + if (strbuf_cmp(&it->last_key, want) >= 0)
> + goto done;
> +
> block_iter_copy_from(it, &next);
> }
>
> --
> 2.44.GIT
>
