Re: reftable [v6]: new ref storage format
- From
Shawn Pearce <spearce@spearce.org>
- Date
- Aug 9, 2017, 00:01 UTC
- Message-ID
- <CAJo=hJt5b=e1-k7FnMixe7vqH8V0ynCHQU80aWKAMJzghU+s3A@mail.gmail.com>
- In-Reply-To
- <xmqqy3qt8wi0.fsf@gitster.mtv.corp.google.com>
On Tue, Aug 8, 2017 at 4:34 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 15 quoted lines
> Shawn Pearce <spearce@spearce.org> writes: > >> Given that the index can now also be multi-level, I don't expect to >> see a 2G index. A 2G index forces the reader to load the entire 2G to >> take advantage of the restart table. It may be more efficient for such >> a reader to have had the writer make a mutli-level index, instead of a >> single monster index block. And so perhaps the writer shouldn't make a >> 2G index block that she is forced to buffer. :) > > Ah, OK, then it is sensible to have all table blocks to have the > same format, and restart at the beginning to help readers would be a > fine choice. For the same "let's make them as consistent" sake, I > am tempted to suggest that we lift "the index block can be 2G" and > have it also be within uint_24(), perhaps? Otherwise the readers > would have to read (or mmap) the whole 2G.
Gah. I just finished moving the restart table back to the end of the block. :)
However, I think I can agree with the index fitting into the uint24 size of 15M, and asking writers making an index that exceeds that to use multi-level indexing.