On Wed, Jan 20, 2021 at 3:50 PM Peter Eisentraut
<peter.eisentraut@enterprisedb.com> wrote:
>
> On 2020-10-30 02:43, Masahiko Sawada wrote:
> > Using the integer set is very memory efficient (5MB vs. 114MB in the
> > base case) and there is no 1GB limitation. Looking at the execution
> > time, I had expected that using the integer set is slower on recording
> > TIDs than using the simple array but in this experiment, there is no
> > big difference among methods. Perhaps the result will vary if vacuum
> > needs to record much more dead tuple TIDs. From the results, I can see
> > a good improvement in the integer set case and probably a good start
> > but if we want to use it also for lazy vacuum, we will need to improve
> > it so that it can be used on DSA for the parallel vacuum.
> >
> > I've attached the patch I used for the experiment that adds xx_vacuum
> > GUC parameter that controls the method of recording TIDs. Please note
> > that it doesn't support parallel vacuum.
>
> How do you want to proceed here? The approach of writing a wrapper for
> bsearch with bound check sounded like a good start. All the other ideas
> discussed here seem larger projects and would probably be out of scope
> of this commit fest.
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.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
