Re: [PoC] Improve dead tuple storage for lazy vacuum

I wrote:

> - Try templating out the differences between local and shared memory.

Here is a brief progress report before Christmas vacation.

I thought the best way to approach this was to go "inside out", that is,
start with the modest goal of reducing duplicated code for v16.

0001-0005 are copies from v13.

0006 whacks around the rt_node_insert_inner function to reduce the "surface
area" as far as symbols and casts. This includes replacing the goto with an
extra "unlikely" branch.

0007 removes the STRICT pragma for one of our benchmark functions that
crept in somewhere -- it should use the default and not just return NULL
instantly.

0008 further whacks around the node-growing code in rt_node_insert_inner to
remove casts. When growing the size class within the same kind, we have no
need for a "new32" (etc) variable. Also, to keep from getting confused
about what an assert build verifies at the end, add a "newnode" variable
and assign it to "node" as soon as possible.

0009 uses the bitmap logic from 0004 for node256 also. There is no
performance reason for this, because there is no iteration needed, but it's
good for simplicity and consistency.

0010 and 0011 template a common implementation for both leaf and inner
nodes for searching and inserting.

0012: While at it, I couldn't resist using this technique to separate out
delete from search, which makes sense and might give a small performance
boost (at least on less capable hardware). I haven't got to the iteration
functions, but they should be straightforward.

There is more that could be done here, but I didn't want to get too ahead
of myself. For example, it's possible that struct members "children" and
"values" are names that don't need to be distinguished. Making them the
same would reduce code like

+#ifdef RT_NODE_LEVEL_LEAF
+ n32->values[insertpos] = value;
+#else
+ n32->children[insertpos] = child;
+#endif

...but there could be downsides and I don't want to distract from the goal
of dealing with shared memory.

The tests pass, but it's not impossible that there is a new bug somewhere.

--
John Naylor
EDB: http://www.enterprisedb.com