Re: Boundary value check in lazy_tid_reaped()

On Wed, Sep 9, 2020 at 7:33 AM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> On Tue, Sep 8, 2020 at 1:23 AM Masahiko Sawada
> <masahiko(dot)sawada(at)2ndquadrant(dot)com> wrote:
> > > > I wonder if you would also see a speed-up with a bsearch() replacement
> > > > that is inlineable, so it can inline the comparator (instead of
> > > > calling it through a function pointer). I wonder if something more
> > > > like (lblk << 32 | loff) - (rblk << 32 | roff) would go faster than
> > > > the branchy comparator.
> > >
> > > Erm, off course that expression won't work... should be << 16, but
> > > even then it would only work with a bsearch that uses int64_t
> > > comparators, so I take that part back.
> >
> > Yeah, it seems to worth benchmarking the speed-up with an inlining.
> > I'll do some performance tests with/without inlining on top of
> > checking boundary values.
>
> It sounds like Thomas was talking about something like
> itemptr_encode() + itemptr_decode(). In case you didn't know, we
> actually do something like this for the TID tuplesort used for CREATE
> INDEX CONCURRENTLY.

BTW I got around to trying this idea out for a specialised
bsearch_itemptr() using a wide comparator, over here:

https://www.postgresql.org/message-id/CA%2BhUKGKztHEWm676csTFjYzortziWmOcf8HDss2Zr0muZ2xfEg%40mail.gmail.com