On Mon, Aug 26, 2019 at 02:46:01PM -0700, harshad shirwadkar wrote: > By this method we end up reading up to 2 extra blocks (one previous > and one next) that are not going to be merged. That's the trade-off we > have to make in order to avoid any changes to on-disk structure (If we > modify the on-disk structure and store the fullness in the dx block, > we would read only the blocks that need to be merged). We can also adjust the merging strategy depending on whether the previous and/or next blocks are in memory. If they are in memory, that we might try merging if the block is < 50% full. If they are not in memory, it might not be worth doing the read until the block is empty, or maybe, say, 10% full. > Since merging approach also requires a way to free up directory > blocks, I think we could first get a patch in that can free up > directory blocks by swapping with the last block. Once we have that > then we could implement merging. I agree; I'd wait to implementing merging until we get directory block removal working. Simply trying to shrink the directory when a leaf block which is *not* the last block in an indexed directory is going to be substantially better compared to waiting until the last block in the directory is empty. - Ted
