On 9/11/21 10:29 PM, Taylor Blau wrote: > On Sat, Sep 11, 2021 at 09:51:04PM -0400, Taylor Blau wrote: >> On Sat, Sep 11, 2021 at 07:59:40PM -0400, Derrick Stolee wrote: >>> I initially hesitated to support the drop of >>> nth_midxed_pack_entry(), since it was designed with things >>> like midx bitmaps in mind (specifically, to also support >>> lex-order-to-stable-order conversions). >> >> I didn't know that nth_midxed_pack_entry was designed with either >> purpose in mind, since it predates midx bitmaps by quite a bit. > > Thinking on it more, I can imagine that you wrote this function > aspirationally envisioning something like MIDX bitmaps. And since you > and I discussed the design together quite a bit, I imagine that that's > the case ;-). > > But I agree that after reading this series again, that the inline-ing > suggested makes sense (and doesn't conflict with any series I have in > flight which don't add any new callers). I'm thinking more to my original design of the multi-pack-index. At that time, I was thinking about the possible integration with bitmaps based on my experience in other systems which used a stable object order to allow writing bitmaps asynchronously with respect to the multi-pack-index write and object packing. One thing that you did when first considering bitmaps over the multi-pack-index was to demonstrate that a stable object order is not required, which surprised and delighted me. It greatly reduced the complexity of the problem, and being able to inline this method is only one small fallout from that simplicity. Thanks, -Stolee
