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

On Tue, Dec 27, 2022 at 12:14 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
wrote:
>
> On Fri, Dec 23, 2022 at 8:47 PM John Naylor
> <john(dot)naylor(at)enterprisedb(dot)com> wrote:

> These 4 patches make sense to me.We can merge them into 0002 patch

Okay, then I'll squash them when I post my next patch.

> and I'll do similar changes for functions for leaf nodes as well.

I assume you meant something else? -- some of the differences between inner
and leaf are already abstracted away.

In any case, some things are still half-baked, so please wait until my next
patch before doing work on these files.

Also, CI found a bug on 32-bit -- I know what I missed and will fix next
week.

> > 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.

Two things came to mind since I posted this, which I'll make clear next
patch:
- A good compiler will get rid of branches when inlining, so maybe no
difference in code generation, but it still looks nicer this way.
- Delete should really use its own template, because it only _accidentally_
looks like search because we don't yet shrink nodes.

> What do you
> think about how we can expand this template method to deal with DSA
> memory? I imagined that we load say radixtree_template.h with some
> macros to use the radix tree like we do for simplehash.h. And
> radixtree_template.h further loads xxx_impl.h files for some internal
> functions.

Right, I was thinking the same. I wanted to start small and look for
opportunities to shrink the code footprint.

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