Re: [PoC] Improve dead tuple storage for lazy vacuum - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: [PoC] Improve dead tuple storage for lazy vacuum
Date
Msg-id CAD21AoCk07=oEY=BQ=tcrSxPGHUgj+pf0gLDhCisKAF-2M0mnw@mail.gmail.com
Whole thread Raw
In response to Re: [PoC] Improve dead tuple storage for lazy vacuum  (John Naylor <johncnaylorls@gmail.com>)
Responses Re: [PoC] Improve dead tuple storage for lazy vacuum  (Masahiko Sawada <sawada.mshk@gmail.com>)
List pgsql-hackers
On Fri, Dec 8, 2023 at 7:46 PM John Naylor <johncnaylorls@gmail.com> wrote:
>
> On Fri, Dec 8, 2023 at 3:06 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> >
> > BTW Given that the actual value size can be calculated only by the
> > caller, how does the tree know if the value is embedded or not? It's
> > probably related to how to store combined pointer/value slots.
>
> Right, this is future work. At first, variable-length types will have
> to be single-value leaves. In fact, the idea for storing up to 3
> offsets in the bitmap header could be done this way -- it would just
> be a (small) single-value leaf.

Agreed.

>
> (Reminder: Currently, fixed-length values are compile-time embeddable
> if the platform pointer size is big enough.)
>
> > If leaf
> > nodes have a bitmap array that indicates the corresponding slot is an
> > embedded value or a pointer to a value, it would be easy.
>
> That's the most general way to do it. We could do it much more easily
> with a pointer tag, although for the above idea it may require some
> endian-aware coding. Both were mentioned in the paper, I recall.

True. Probably we can use the combined pointer/value slots approach
only if the tree is able to use the pointer tagging. That is, if the
caller allows the tree to use one bit of the value.

I'm going to update the patch based on the recent discussion (RT_SET()
and variable-length values) etc., and post the patch set early next
week.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Remove some unnecessary includes of "access/xlog_internal.h"
Next
From: Nikolay Shaplov
Date:
Subject: Re: [PATCH] New [relation] option engine