On Tue, Mar 9, 2021 at 9:57 AM Masahiko Sawada <sawada.m...@gmail.com> wrote: > > On Mon, Mar 8, 2021 at 7:16 PM Peter Eisentraut > <peter.eisentr...@enterprisedb.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/
bound_check_lazy_vacuum_noinline.patch
Description: Binary data
