Re: BTScanOpaqueData size slows down tests

On 2025-Apr-02, Peter Geoghegan wrote:

> On Wed, Apr 2, 2025 at 12:31 PM Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
> > The mentioned commit (09cb5c0e7d6f) shows that we do partial memcpys, e.g.
> >
> > + memcpy(&so->markPos, &so->currPos,
> > + offsetof(BTScanPosData, items[1]) +
> > + so->currPos.lastItem * sizeof(BTScanPosItem));
> >
> > That would obviously not work if this field weren't last. We still do
> > that, don't we? See btrestrpos().
>
> Yes, we do -- but it's rare. It only happens in the case where we
> restore a mark after leaving the page where the mark was taken. In
> practice, merge joins tend to hardly ever do that (I know this because
> it makes testing annoyingly difficult). In other words, the
> optimization added by commit 08ae5edc5c seems to be very effective in
> practice.

I'm just saying that this is the reason to have the field be last in the
struct.

--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"La rebeldía es la virtud original del hombre" (Arthur Schopenhauer)