blob: add support for a 'long attribute' stored alongside handle

[jbowens]

With value separation, the cost of retrieving a value increases—an iterator may need to perform two additional block loads (one for the blob file index and one for the blob value block)

In CockroachDB, uncertainty interval checks require reading KVs' "local timestamp". This timestamp is encoded within the key-value pair's value (specifically as a field the MVCCValue protocol buffer). In mostsome cases, CockroachDB has no other need for the value other than retrieving this local timestamp.

To avoid retrieving the value just for the local timestamp, we'd like to add support for allowing a user to specify a LongAttribute that should be encoded alongside/within the inline blob handle when a value is separated. Then we should extend the LazyValue type to allow extraction of the LongAttribute from the blob handle suffix.

See the ShortAttribute type for an analogous concept that allows the user to stuff a few bits derived from the value into the block.ValuePrefix when a value is separated.

There's some prior art in @sumeerbhola's value separation prototype: master...sumeerbhola:pebble:blobt2#diff-536ef24c119680fc300327ac83776a1a1672559ca824078340345d8151a0074cR247-R267

Jira issue: PEBBLE-417

Epic CRDB-20379

[RaduBerinde]

This would also be very useful for tiering. SQL would put the tiering value (timestamp) separately in roachpb.Value.

[RaduBerinde]

Ideally the local timestamp should become a different column rather than being part of the blob handle. We should think of a general way of mapping MVCCValue fields to columns instead of proto-encoding it.

[jbowens]

Yeah, maybe the caller should specify a colblk.KVSchema instead of a colblk.KeySchema and be allowed to specify which columns are guaranteed in-place. We don't have a need for it today, but if we do #4483 we can encode non-in-place columns within a blob block. This might eventually be useful for predicate pushdown.