With respect to “not 100%” for index packing…
On 13 Jan 2023, at 11:17, David G. Johnston wrote:
> I'll admit it seems a bit counter-intuitive, and there really isn't a "why"
> offered in the user-facing documentation, but for 10% I'm not too worried
> about it.
>
I have had the same “why” and this conversation got me thinking…
The resulting “why” is based on what would be needed to maintain the ACID requirement while the index is both in use
andbeing reorganised. Specifically, when one worker is using the index it has its “horizon” (ie., version) of the index
fixed,another worker might add to the data forcing an index rebalance, this means two, and maybe more, workers are in
thesame index each has their view/version of that one index. This “multiverse” is supported by multiple versions of any
givennode. This can be accommodated in the spare part of the index packing. The spare space allows the index
rebalancingto be written into blocks that may already be buffered. Once the index rework is complete, WAL has been
written,ACID compliance assured then the revised index (with all its freshly written nodes) is declared open for
businessand new workers will get this version for their horizon. Older workers will complete on their version, and the
nodessupporting their view will then out of date, and the space can return to the block’s free area . The cycle
repeats…
Likely I have many of the details wrong but it’s an explanation that’s good enough for my purposes. :)
Gavan Schneider
——
Gavan Schneider, Sodwalls, NSW, Australia
Explanations exist; they have existed for all time; there is always a well-known solution to every human problem —
neat,plausible, and wrong.
— H. L. Mencken, 1920