Re: reftable [v6]: new ref storage format

I notice that you raised the location of restart table within a block in this iteration (or maybe it happened in v5).

This forces you to hold all contents in core before the first byte is written out. You start from the first entry (which will become the first restart entry), emit a handful as prefix compressed entries, emit a full entry (which will become the next restart entry), ... until you have enough to fill both the data and the restart table, then start writing from the header (which needs the length of the block), restart table and then data.

I think it is OK to do so for the blocks whose size is limited to 16M, but I wonder if it is sensible to do the same for the index block whose limit is 2G. If you keep the restart table after the data, then you could stream out the entries as you emit, write the restart table, and then seek back to fix the length in the header, without holding the 2G in core, no?