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@alvh.no-ip.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)