Re: Boundary value check in lazy_tid_reaped()

On Tue, Mar 9, 2021 at 9:57 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> On Mon, Mar 8, 2021 at 7:16 PM Peter Eisentraut
> <peter(dot)eisentraut(at)enterprisedb(dot)com> wrote:
> >
> > On 21.01.21 14:11, Masahiko Sawada wrote:
> > > Agreed. bsearch with bound check showed a reasonable improvement in my
> > > evaluation in terms of performance. Regarding memory efficiency, we
> > > can experiment with other methods later.
> > >
> > > I've attached the patch that adds a bound check for encoded
> > > itermpointers before bsearch() in lazy_tid_reaped() and inlines the
> > > function.
> >
> > Do you have any data showing the effect of inlining lazy_tid_reaped()?
> > I mean, it probably won't hurt, but it wasn't part of the original patch
> > that you tested, so I wonder whether it has any noticeable effect.
>
> I've done some benchmarks while changing the distribution of where
> dead tuples exist within the table. The table size is 4GB and 20% of
> total tuples are dirty. Here are the results of index vacuum execution
> time:
>
> 1. Updated evenly the table (every block has at least one dead tuple).
> master : 8.15
> inlining : 4.84
> not-inlinning : 5.01
>
> 2. Updated the middle of the table.
> master : 8.71
> inlining : 3.51
> not-inlinning : 3.58
>
> 3. Updated both the beginning and the tail of the table.
> master : 8.44
> inlining : 3.46
> not-inlinning : 3.50
>
> There is no noticeable effect of inlining lazy_tid_reaped(). So it
> would be better to not do that.

Attached the patch that doesn't inline lazy_tid_reaped().

Regards,

--
Masahiko Sawada
EDB: https://www.enterprisedb.com/