sstable: add writer option to remove a common prefix

[dt]

No description provided.

[cockroach-teamcity]

This change is 

[dt]

I'm guessing the elided-prefix prop is what's making the readers 16 bytes bigger, via the extra string header in the props? We don't strictly need this prop so I could... skip it? I figured it'd be nice to have so we could tell by looking at an sst if someone hacked some prefix out of its content during creation, but I suppose when everything works as intended we'll know this based on other metadata.

[sumeerbhola]

Reviewable status: 0 of 8 files reviewed, 1 unresolved discussion (waiting on @dt, @itsbilal, and @RaduBerinde)

---

sstable/writer.go line 1237 at r1 (raw file):

		}
		key.UserKey = key.UserKey[len(w.elidePrefix):]
	}

what about the encoded keyspan.Span.End that is contained in value? Don't we need to confirm that it has the elidePrefix and strip the prefix?

[RaduBerinde]

sstable/writer.go line 1237 at r1 (raw file):

Previously, sumeerbhola wrote…

what about the encoded keyspan.Span.End that is contained in value? Don't we need to confirm that it has the elidePrefix and strip the prefix?

It would be unfortunate to decode/reencode the values and account for all cases in here, when we just encoded them before calling this function.

I wonder if we should replace AddRangeKey with "already fragmented" variants of RangeKeySet, RangeKeyUnset, RangeKeyDelete. It would also make existing order-checking code easier.

[sumeerbhola]

Reviewable status: 0 of 8 files reviewed, 1 unresolved discussion (waiting on @itsbilal and @RaduBerinde)

---

sstable/writer.go line 1237 at r1 (raw file):

It would be unfortunate to decode/reencode the values and account for all cases in here, when we just encoded them before calling this function.

IIRC, there are two paths:

• where fragmentation is done in the writer. These call into addRangeKeySpan.
• fragmentation is done outside the writer. Compactions and suffix rewriting are using this path. The compaction case is a very shallow use rangekey.Encode(&v, tw.AddRangeKey), so we could expose a Writer.AddRangeKeyPrefragmented(*keyspan.Span) and do the encoding here. Suffix rewriting is similarly shallow. I think this is similar to what you are suggesting, except we can make do with one method.