Re: BTScanOpaqueData size slows down tests - Mailing list pgsql-hackers

From Álvaro Herrera
Subject Re: BTScanOpaqueData size slows down tests
Date
Msg-id 202504021643.q6tn6hddwknh@alvherre.pgsql
Whole thread Raw
In response to Re: BTScanOpaqueData size slows down tests  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: BTScanOpaqueData size slows down tests
List pgsql-hackers
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)



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Statistics Import and Export
Next
From: Andres Freund
Date:
Subject: Re: Parallel CREATE INDEX for GIN indexes