Investigate: Disaggregated storage stat cursor slow path seems redundant

XMLWordPrintableJSON

      Investigations from two different sources, BF-44448 and a the logical size project work have both identifed inefficiencies / bugs in the stat cursor fast path for disagg. 

      Ideally a user provides "statistics:size" alongside a URI and WiredTiger will fetch the size from the metadata, however if it finds a zero size it then opens the dhandle and fetches the size from the dhandle, which fetches the size from the metadata... 

      The contract perhaps needs reinforcing, but if both paths end up in the metadata file then we should simply never take the slow path and return 0 to the caller. Alternatively if the ident does not yet exist a ENOENT error is ideal.

      The open question that I can see is, when if ever can the size be zero in the metadata?And is this a case we care about? I can think of potentially two cases:

      1. Fake checkpoints, zero might not be correct here?
      2. An empty root checkpoint, in which case zero is correct

      This impacts the dhandle scalability work and should be worked on as priority, but any changes made here to the contract will impact the database size work, and by extension the logical size work and should be made carefully...

            Assignee:
            Krishen Chovhan
            Reporter:
            Luke Pearson
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: